[swift-evolution] Analysis of case conventions for initialisms
Jordan Rose
jordan_rose at apple.com
Fri Feb 12 15:31:28 CST 2016
Addendum: another problem with convention #2 is that the rule produces "Mccall", "Iphone", and "Latex" along with "Html", all of which are less readable (for me, in context of a larger identifier like "IphoneViewController") than the convention #1 output.
(At least, my understanding of the convention #2 rule.)
> On Feb 12, 2016, at 11:12, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>
> (re: https://gist.github.com/dabrahams/55fc5ece355da4664730 <https://gist.github.com/dabrahams/55fc5ece355da4664730>)
>
> I am very strongly in favor of convention #1, and it comes from what we were talking about offline yesterday. This is what I do pretty much automatically when coding:
>
> Word Lowercase "Capitalized" Uppercase
> string string String STRING
> Cupertino cupertino Cupertino CUPERTINO
> McCall mccall McCall MCCALL
> HTML html HTML HTML
> iPhone iphone IPhone IPHONE
> LaTeX <https://en.wikipedia.org/wiki/LaTeX> latex LaTeX LATEX
>
>
> (apologies to those reading this in plain text)
>
> The important thing here is that the "capitalize" operation doesn't mess with the case of any other letters in the word. My preferred rules are then:
>
> • To form a type name, "capitalize" every component, then concatenate.
> • To form a value name, "lowercase" the first component, "capitalize" every other component, concatenate.
>
> which is pretty much convention #1.
>
> (My "capitalize" rule for coding breaks the rule for publication, in which "iPhone" would be the capitalized form. Without it, however, you end up with names like "isUsingiPhone" and "DefaultiPhoneViewController", which I agree are harder to read than "isUsingIPhone" and "DefaultIPhoneViewController".)
>
> This isn't quite what Cocoa does (as noted by Dave, it prefers to not lowercase initialisms or acronyms in value names, leaving them all uppercase), but it's what I do in practice.
>
> Regarding the other suggestions:
>
> • "HtmlString" (a type) makes me uncomfortable because there isn't a word "Html" or "html"; that is, it's not the output of any of my built-in mental operations.
> • "hTMLString" (a value) is nonsense to me; that's three words "h", "TML", and "String".
> • I really don't find "XmlRpcConnection" easier to read than "XMLRPCConnection". Easier to break up into words, yes; easier to recognize what those words are, no.
>
> Jordan
>
>
>> On Feb 11, 2016, at 21:51, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>> I just posted a write-up about various case conventions for initialisms:
>> https://gist.github.com/dabrahams/55fc5ece355da4664730 <https://gist.github.com/dabrahams/55fc5ece355da4664730>. I was surprised
>> at how it turned out, FWIW.
>>
>> Cheers,
>>
>> --
>> -Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/11d319f3/attachment.html>
More information about the swift-evolution
mailing list