[swift-evolution] Analysis of case conventions for initialisms
dabrahams at apple.com
Fri Feb 12 01:05:07 CST 2016
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
>> https://gist.github.com/dabrahams/55fc5ece355da4664730. I was
>> 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.
> 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?
More information about the swift-evolution