<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 3:37 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> Maybe that would get better with time, but this is something that<br>
>> every new Swift developer would go through.<br>
><br>
> This is clearly highly subjective. Some people have no problem with it.<br>
<br>
</span>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.<br>
<span class=""><br></span></blockquote><div><br></div><div>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 <i>examples</i> 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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> Bottom line for me: If #2 was the convention, I'm about 90% certain I<br>
>> would simply flat out ignore it when I named things, and cringe when I<br>
>> had to use someone else's names. I don't think we should adopt a<br>
>> naming convention that makes users cringe.<br>
><br>
> So what convention doesn't make you cringe? Would you accept any of the<br>
> others there, or is it something else?<br>
<br>
</span>I like #3, and #1 is quite acceptable as well.<br>
<br>
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.<br>
<br>
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.<br>
<span class=""><br>
> As I mentioned to Marco, if you'd like to create an amended document<br>
> that accounts for that one, too, I'd be happy to incorporate it.<br>
> However, note that I've tried pretty hard to stay away from subjective<br>
> factors in the analysis; it would be good if you could do the same.<br>
<br>
</span>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.<br>
<br>
(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?)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>