naming conventions redux

Ian Young ian at iay.org.uk
Mon Jul 1 04:50:30 EDT 2013


Sigh.  Sorry about this, but the problem with coding conventions is that one is always running up against edge cases…

I updated the coding conventions page:

https://wiki.shibboleth.net/confluence/display/DEV/Java+Coding+Conventions

to reflect the decision we took in May:

> Abbreviations and acronyms should be uppercased when used as part of a name: for example, getURL() rather than getUrl().  This applies even when more than one acronym appears together, as in getLDAPURL(), but picking names so that this doesn't happen will make you more popular.  [Decided: 2013-05-31]

Looking at it again, of course I found myself wondering whether we actually wanted the new rule to apply to "abbreviations and acronyms" or just to "acronyms".  Obviously the getLDAPURL case we obsessed about only included acronyms.

I'm also kind of at a loss to think of many places we actually use abbreviations as opposed to acronyms.  The most obvious seems to me to be "identifier" which we have historically rendered as "id" as in "setId" and "getId".  It doesn't seem to me that an abbreviation should in fact end up upper-cased.

What I propose is that we say that the given rule applies to acronyms, and that abbreviations should hold to the previous rule (not uppercased).

If people are agreeable, I'll change the existing rule to apply to just acronyms, and add a new one to describe abbreviations in the same terms as the old rule.  If this seems problematic, some counter-examples would be good to have.

	-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130701/f65d9a1e/attachment.bin 


More information about the dev mailing list