Hi,

I think that representing acronyms as 'words' in class names should be
generally preferred:

Url url = ...  is better than  URL uRL = ...
and
UrlUriConverter is more readable than URLURIConverter

Pete

On Thu, Nov 18, 2010 at 11:25 AM, Vincent Hennebert
<vhenneb...@gmail.com> wrote:
> Hi Simon,
>
> On 17/11/10 20:29, Simon Pepping wrote:
>> On Wed, Nov 17, 2010 at 07:45:31PM -0000, spepp...@apache.org wrote:
>>> Author: spepping
>>> Date: Wed Nov 17 19:45:27 2010
>>> New Revision: 1036179
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1036179&view=rev
>>> Log:
>>> findbugs-reported bug squashing; 959 bugs left (findbugs 1.3.9)
>>
>> findbugs reports naming problems in public methods, such as setters
>> and getters. I resolved those problems. But in doing so, in principle
>> I am changing the public API. I do not think that every public method
>> is really in use by other applications. Let me know when I go too far
>> in those changes, harming applications that depend on fop.
>
> Good work, thanks for that. There are a few renamings that I’m not sure
> I agree with, though:
>
> • an ID is written ID, all upper case. Id is something else [1] that
>  I believe is outside the scope of FOP ;-)
>  So I would keep the names setID and getID, and not rename them into
>  setId/getId. Affected classes are o.a.f.apps.PageSequenceResults,
>  o.a.f.render.intermediate.extensions.AbstractAction and
>  o.a.f.render.intermediate.extensions.URIAction
>
>  [1] http://www.thefreedictionary.com/ID
>
> • likewise, URI is an acronym that’s always written upper case, and
>  I think that should remain so. FWIW, the Java standard library uses
>  names like toURI, toURL, etc. Affected classes are
>  o.a.f.render.afp.AFPRendererImageInfo and
>  o.a.f.render.ps.PSImageFormResource
>
> • namespace is not theoretically an English word but its use has been so
>  pervasive (in the W3C Namespaces recommendation, to start with), that
>  I would keep it like this. Affected classes are
>  o.a.f.render.XMLHandler and descendants.
>
> WDYT?
> Thanks,
> Vincent
>

Reply via email to