[swift-evolution] Analysis of case conventions for initialisms
jordan_rose at apple.com
Fri Feb 12 13:12:35 CST 2016
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.
> On Feb 11, 2016, at 21:51, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> I just posted a write-up about various case conventions for initialisms:
> https://gist.github.com/dabrahams/55fc5ece355da4664730. I was surprised
> at how it turned out, FWIW.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution