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. - Jonathan M Davis
