I prefer the current style. It's more common and closer to the specs.
Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a mix
of Xml and XML, Http and HTTP.
(With deviation from any rules where obvious readability improvements
result.)
Digressing - I found that an identifier of "_" now generates a warning
in Java8 (not that I would use a single _ much refer $) becaue ti's
going to be removed. Anyone know the background to that? Scala
alignment maybe?
Andy
On 17/03/15 09:51, Reto Gmür wrote:
I know it's just a detail and there is no clear right or wrong. Still I'd
like to have a conscious decision on how to do the casing so we can apply
it consistently everywhere.
Approaches:
A) Acronyms are treated like normal words, i.e. only the first character is
uppercased, this is what the google style guide recommends [1]
B) Acronyms are uppercased as a whole
C) 2-Letter acronyms are uppercased, longer are treated like normal words
(this seems to be the .Net convention)
I personally prefer the first approach for the following reasons:
- IDEs get it right, the default name for the result of getRdfUiApiKey() or
a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or key)
not rDFUIAPIKey.
Eclipse gets it right for any convention for me.
- It's more readable, the acronyms are the individual words, the case
distinctions allows to recognize them quickly
- It's not always obvious is something is an abbreviation or any acronym,
while it might seem OK to uppercase some abbreviations like "OK" or "ID"
uppercasing other abreviations would look quite strange (e.g.
"LiteralIMPL"). So for consistency treat acronyms like abbreviations like
normal words.
WDYT?
?Wdyt !
Reto
1.
https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
