Jonathan M Davis wrote: > On Thursday, September 15, 2011 09:46:13 Jens Mueller wrote: > > Jonathan M Davis wrote: > > > On Wednesday, September 14, 2011 16:12 Jens Mueller wrote: > > > > Jonathan M Davis wrote: > > > > > On Wednesday, September 14, 2011 15:36 dsimcha wrote: > > > > > > On 9/14/2011 5:24 PM, Vladimir Panteleev wrote: > > > > > > > Tiny nitpick: case of "GC" in type/enum names should > > > > > > > probably match for consistency. > > > > > > > > > > > > Good point. Do we even have a convention for acronyms in > > > > > > variable/type names? If so is it GcAllocator or > > > > > > GCAllocator? > > > > > > > > > > We haven't been entirely consistent. For instance, we have > > > > > UtfException, but _every_ other case of utf in the code is > > > > > either utf (at the beginning of a function) or UTF (I have a > > > > > pull request which includes fixing the casing on UtfException > > > > > to match everything else). Given the choice, I'd definitely say > > > > > that GC should be used and not Gc, and everywhere in Phobos > > > > > where I've created a function which had an acronym in it, > > > > > that's what I've done, but without going through the whole code > > > > > base, I don't know which convention is more common (other than > > > > > the case of Utf where I did go looking; it's easier when you > > > > > know what the acronym is rather than looking for _all_ > > > > > acronyms). I don't think that acronyms have been all that > > > > > common in general though. > > > > > > > > When I had first glance at GCAllocator I observed this as well. I > > > > believe GcAlloctor is the better way to camelize it even though > > > > druntime has a class GC. It's easier to read for me, consider > > > > XMLToHTMLConverter vs. XmlToHtmlConverter or worse XMLHTMLConverter > > > > vs. XmlHtmlConverter. See > > > > http://stackoverflow.com/questions/1176950/acronyms-in-camel-back> > > > Actually, I find XMLToHTMLConverter to be more legible than > > > XmlToHtmlConverter, because XML and HTML are pretty much always > > > capitalized everywhere else, and so Xml and Html are unfamiliar and > > > jarring. Acronyms are meant to be capitalized. So, the natural thing to > > > do is to put them in all caps in camelcased names. The problem is that > > > you then end up with stuff like XMLTo where the first part of the next > > > word in the name is capitalized but isn't part of the acronym, which is > > > a bit funny. It's completely consistent and legible that way though. > > > There's no confusion over whether the T is part of XML or not. It's > > > just arguably a bit ugly. But _not_ capitalizing acronyms is generally > > > far more hideous IMHO and makes them harder to read, because they're > > > pretty much always capitalized everywhere else. > > > > I think that are capitalized everywhere else because they are separated > > by spaces in these cases. > > But how about XMLHTMLConverter? Because I believe you then have to > > accept this as well without making the rule complicated. Also your > > argument is only valid for acronyms you know already. What does a > > DSAFUSLConverter do? I just made this to illustrate the point. > > Part of what you have to do is pick good names. XMLHTMLConverter is a bad > name > regardless of how you capitalize it. Acronyms are usually capitalized because > they stand for something. It's highly abnormal _not_ to capitalize them. > Spaces have nothing to do with it. One of the few places that that ever > happens is in symbol names in some programs, because the programmers involved > thought that it was ugly to have that many capital letters in a row. Outside > of programming, not capitalizing them is rare, and inside of programming, it > depends on who's writing the code. > > Personally, I do _not_ like it when acronyms have mixed capitalization, and I > think that symbol names with fully capitalized acronyms are just fine. You > just > need to be smart about what you name your symbols - which you should be doing > anyway.
Either way it'll be nice to have this fixed in the style guide. Even though I prefer the Java/.NET convention for acronyms. Maybe we can just decide this and move on. Jens
