[swift-evolution] Analysis of case conventions for initialisms

[Jonathan Tang]

+1 for #2, which is also what Java and Google code conventions do.  It
looks awkward at first, but being able to distinguish word boundaries is
surprisingly important.  Tech is rife with initialisms; you could
realistically have a class or constant like AWSS3RPCURL where every single
letter is part of an initialism.

On Thu, Feb 11, 2016 at 10:52 PM, Brent Royal-Gordon via swift-evolution <
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.
>
> (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
>
> _______________________________________________
> 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/20160211/21af276e/attachment.html>