Hi Reto, Could you name the types that you are referring to? The image I am looking at doesn't contain them:
https://github.com/commons-rdf/commons-rdf/raw/master/api/src/main/resources/commons-rdf-class-diagram.png Thanks, Peter On 19 March 2015 at 22:47, Reto Gmür <[email protected]> wrote: > 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 >> >> >> >> >> > >> >> >>
