[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