[swift-evolution] Analysis of case conventions for initialisms

[Brent Royal-Gordon]

>> 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.

>> 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