[swift-evolution] Analysis of case conventions for initialisms

[Trent Nadeau]

+1 for Option #2
-1 for Option #1
-Infinity for Option #3

On Fri, Feb 12, 2016 at 2:46 PM, Austin Zheng via swift-evolution <
swift-evolution at swift.org> wrote:

> Sorry, just to be pedantically precise "acronym" should really be "acronym
> or initialism that is conventionally written as a sequence of capital
> letters".
>
> On Feb 12, 2016, at 11:15 AM, Austin Zheng <austinzheng at gmail.com> wrote:
>
> +1. I prefer to always capitalize acronyms. Option #1 is a decent
> alternative (because of the type name argument), then #3. I personally
> dislike the suggestions that write out an acronym in a way that mixes case.
>
> Austin
>
> On Feb 12, 2016, at 3:04 AM, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I’m a +1 for capitalising acronyms, so HTMLValidator rather than
> htmlValidator. I know it isn’t /quite/ as clear that HTML and Validator are
> separate pieces, but I don’t think it’s unclear, since the V is the last
> capital letter in the sequence of capitals.
>
> That said I’m a little less sure on function and property names; I prefer
> them to always begin lower case, and a result I prefer any acronyms to be
> towards the end. This also helps with function naming where I prefer a
> function to describe an action first.
>
> For example, I would change the following:
>
> title.htmlEncode
>
> To one of the following:
>
> title.encodeHTML()
> title.encodeForHTML()
>
> Since to me encode is the action, it being for HTML is a variation of that
> action. In fact, if the function belongs to an HTMLValidator type then I’d
> drop the HTML from method/property names entirely as I’d say that it’s
> implied. While the type may not always be visible to imply it, well chosen
> variable names should ensure it remains clear. For example, instead of
> .validHTML I’d do the following with a clear variable name:
>
> let isValidHTML = HTMLValidator(page.webaddress).valid
>
> So in other words, I’m all about an option that’s not quite any of those
> listed, just to be really awkward ;)
>
> To summarise it though, I’d always capitalise the acronyms, but for
> property and method names I’d prefer a verb or noun to lead the name so
> that the acronym trails, or can be omitted if it’s implied by context (the
> type to which the method/property belongs).
>
> On 12 Feb 2016, at 10:20, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> on Fri Feb 12 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:
>
> Based on the examples, #2 does seem to have the most advantages. But:
> what to do with vendor prefixes? Are those to be an exception?
>
>
> Can you some examples of a “vendor prefix?”
>
> Another tidbit: .NET seems to have its own exceptions--not sure if
> there are rules for them, but just at the namespace level there's
> System.IO and UIAutomationClientsideProviders, spelled as shown.
>
>
> Thanks for pointing those out.
>
>
>
> On Fri, Feb 12, 2016 at 3:07 AM, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>
>
> on Fri Feb 12 2016, Rob Mayoff <swift-evolution at swift.org> wrote:
>
> I have been using #2 for years in many languages (including Objective-C and
> more recently Swift) and much prefer it.
>
> Incidentally, "ASCII" is one of the examples in the definition of "acronym"
> in OS X's American English dictionary.
>
>
> Yup, you're right.
>
> On Thu, Feb 11, 2016 at 11:51 PM, Dave Abrahams 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.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> 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
>
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> 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
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/4f415277/attachment.html>