[swift-evolution] Analysis of case conventions for initialisms

[Jonathan Tang]

On Fri, Feb 12, 2016 at 3:37 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> >> Maybe that would get better with time, but this is something that
> >> every new Swift developer would go through.
> >
> > This is clearly highly subjective.  Some people have no problem with it.
>
> I strongly suspect, though I cannot prove, that it's not so much that some
> people have no problem with it as that some people are already acclimated
> to it. I would be interested to learn if the #2 voters have previous
> experience using that style.
>
>
Early (pre-2001 or so) Google code used option #1, and then preferences
switched to option #2 around 2002 or 2003.  (I don't think it's ever stated
explicitly in the styleguide, but the *examples* there use option #2, so
that's what was called for in code reviews.)  Yes, that means that you will
occasionally write abominations like operating on HTMLTokens with
HtmlUtils.  I have a pretty strong preference for never changing the
convention once it's set (stronger than any of my preferences for each
individual option).  Indeed, if there's a lot of Cocoa or standard library
code that non-negotiably uses an existing convention, that's a very strong
argument to go with that convention regardless of what everyone thinks here.

I voted for #2.  I want to make it clear that I had a very similar reaction
to it as you when I first saw it in the Java styleguides.  Most of my
personal code actually uses #1, but then, I tend to use snake_case in my
personal code when freed from any existing organization's styleguide, which
is apparently off the table for Swift.  I've found that you do eventually
get used to titlecased initialisms like Url, Rpc, and Html; they look gross
at first, but soon they become just another programming idiosyncracy, like
the parentheses in Lisp or the semicolons in every other language.
However, you do *not* get used to things like RPCURL or XMLLALRParser; they
happen just infrequently enough to throw you for a loop when they do occur,
but then when that happens, you need to stare at them and parse out each
individual letter to understand the identifier.  It's even worse when they
happen to spell out another programming concept; I can't look at RPCURL
without seeing R-P-CURL, or read IOSSystemCall as IO-System-Call instead of
iOS-System-Call.


> >> Bottom line for me: If #2 was the convention, I'm about 90% certain I
> >> would simply flat out ignore it when I named things, and cringe when I
> >> had to use someone else's names. I don't think we should adopt a
> >> naming convention that makes users cringe.
> >
> > So what convention doesn't make you cringe?  Would you accept any of the
> > others there, or is it something else?
>
> I like #3, and #1 is quite acceptable as well.
>
> I'd like to talk briefly about *why* I think #3 is okay. We do lose the
> "capital letter means type" cue, but I'm willing to tolerate that
> ambiguity. I think of types as being an abstraction of
> values—`numberOfRows` is some particular integer, but `Int` is the abstract
> concept of an integer. In a sense, a type is like a Platonic Form, and so
> we borrow the convention of capitalizing them to distinguish them from
> their concrete instances. When we want to incorporate an acronym, which is
> always uppercased, into the name of a concrete instance, that convention
> breaks down, but that's okay—it's just a convention, not an iron law of
> Swift identifiers.
>
> I think that, to some extent, the decision here is a tradeoff between
> ambiguity and natural appearance. Perhaps I simply have a greater tolerance
> for ambiguity and dislike of unnatural appearance than the #2 supporters.
>
> > As I mentioned to Marco, if you'd like to create an amended document
> > that accounts for that one, too, I'd be happy to incorporate it.
> > However, note that I've tried pretty hard to stay away from subjective
> > factors in the analysis; it would be good if you could do the same.
>
> I think it makes sense to try to stay away from subjective factors in your
> analysis, but I don't think we can make the actual decision without
> considering them. If you really want to make the word boundaries obvious,
> the best solution is to use underscores in identifiers anywhere you would
> normally put a space. We don't do that because of a subjective judgement
> that underscores in identifiers are ugly.
>
> (If you're editing the analysis, though, one thing confuses me about #3:
> Why is 'Encourages “spelling” rather than “pronouncing” the initialism'
> only 2/3?)
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/6f533615/attachment.html>