[swift-evolution] Analysis of case conventions for initialisms

[Dave Abrahams]

on Thu Feb 11 2016, Brent Royal-Gordon <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.
>
> 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.

Yeah, it's a poor name, but people do it anyway, and there are still
plenty of legitimate uses for names *starting* with "url"

> (That's not to say I haven't done this; I certainly have. 

See, there?

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

It's an interesting angle, but does banning “urlToOpen” or “asciiSpace”
(pick your favorite spelling convention) really make sense?


-- 
-Dave