[swift-evolution] Analysis of case conventions for initialisms
Jon Shier
jon at jonshier.com
Fri Feb 12 15:52:58 CST 2016
I find myself distinctly unimpressed by the “argument from other languages” presented in favor of #2. Any “rule” considered here should be able to stand on it’s own logical merits, no matter what other languages may do.
#1: Interesting and acceptable. I find the type vs. variable name argument somewhat weak, since it’s almost always clear by usage what it is. However, the consistent upper or lower casing still relays the fact that a word is an acronym or initialism fairly clearly, though not as strongly as #3.
#2: Unacceptable, as it completely ruins any notion of the words being an acronym or initialism. In normal writing, initialisms are easy to see, and are read by saying each letter separately. To me, this fact completely outweighs the argument for clearer word boundaries, since the letters, read separately, are the words of an acronym or initialism. So XMLRPCConnection is read as “ex em el ar pee cee connection (excuse the incorrect phonetics), and writing it as XmlRpcConnection just confuses the user at first glance about whether the words are words or a’s/i’s, especially if the a/i is somewhat uncommon.
#3: This is largely my personal style, though I sometimes uppercase initialisms/acronyms used as variable names as well. This style makes usage almost entirely consistent across the language, and largely consistent with normal usage. There’s still the question of variable names, but that’s rather minor, and can be improved with better variable names, as already mentioned.
Jon Shier
More information about the swift-evolution
mailing list