[swift-evolution] Analysis of case conventions for initialisms

[Austin Zheng]

+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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> on Fri Feb 12 2016, Xiaodi Wu <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> on Fri Feb 12 2016, Rob Mayoff <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> I just posted a write-up about various case conventions for initialisms:
>>>>>> https://gist.github.com/dabrahams/55fc5ece355da4664730 <https://gist.github.com/dabrahams/55fc5ece355da4664730>.  I was surprised
>>>>>> at how it turned out, FWIW.
>>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> --
>>>> -Dave
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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

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