[swift-evolution] Analysis of case conventions for initialisms

[Brent Royal-Gordon]

> 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.

This is perhaps not a practical answer, but honestly, I'm having trouble thinking of a case where a variable name that's an initialism is a *good* name. Initialisms often make sense as types—HTML, URL, UUID, etc. But as variable names, they tend to be overly vague. For instance, in the example you give:

	func saveToURL(
	  _ url: NSURL,
	  forSaveOperation saveOperation: UIDocumentSaveOperation,
	  completionHandler completionHandler: ((Bool) -> Void)?)

`url` is not really a very descriptive name for the parameter; it would probably be better as `destinationURL` or `fileURL` or `documentURL`. You might even want to drop the `URL` from the end of those, making `destination`, `file`, or `document`. The name `url` is about as descriptive as `block` would be for the last parameter.

(That's not to say I haven't done this; I certainly have. But I'm thinking that maybe the code where I did it wasn't as good as it could have been.)

So I wonder if we shouldn't instead guide that initialisms should not appear at the beginning of variable names. You should name your variables (and properties) for their semantic, not their type.

If initialisms don't appear at the beginning of variable names, then you can distinguish between types and variables by capitalization. That leaves only the word boundary issues, which I think we can live with.

-- 
Brent Royal-Gordon
Architechies