Hi Peter In the clerezza version there are 3 and in the github version there are 4 types in the API that would have to be renamed. Additionally there are classes in the implementations that follow the same pattern.
I can live with either version, and would probably even want to stick to it even when new acronyms are in use. I would like to have a decision so that we either adapt the github code when importing it or we change the code at clerezza commons rdf. Cheers, Reto On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <[email protected]> wrote: > Hi Retro, > > In our case, there is only ever one acronym in a class name at this > point, so we should be fine with just uppercasing it without dealing > with the complexities you are referring to. If we ever find ourselves > in a position with multiple acronyms in a class name we can come back > to it. > > Cheers, > > Peter > > On 18 March 2015 at 19:22, Reto Gmür <[email protected]> wrote: > > I think the approach Andy suggested isn't in the three options of my > > original mail. So let me try to paraphrase it: > > > > d) If possible acronyms are cased as they appear in the specs (default > > casing), if they appear in a position where an uppercase first letter is > > required (and this letter is not uppercase in the default casing) then > only > > this letter is uppercased, if they appear in a position where a lowercase > > first letter is required then the whole acronym is lowercased. Where > > obvious readability improvements result a different casing can be chosen. > > > > So for example (with RDF, RDFa, sbt and iOS): > > > > RDFSbtPlugin - rdfSbtPlugin > > RDFaSbtPlugin - rdfaSbtPlugin > > IOSRDFTools - iOSRDFTools > > > > Is this the variant you Peter/Andy prefer? > > > > Cheers, > > Reto > > > > > > > > On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <[email protected]> > > wrote: > > > >> +1, I prefer the current style and no clear reason why the other > >> possibility would be more beneficial for us at this point. > >> > >> Cheers, > >> > >> Peter > >> > >> On 17 March 2015 at 22:27, Andy Seaborne <[email protected]> wrote: > >> > 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 > >> >> > >> > > >> >
