[swift-evolution] [Review] SE-0023 API Design Guidelines
Erica Sadun
erica at ericasadun.com
Sat Jan 23 18:43:39 CST 2016
I am a fan of uppercasing global constants and functions. However, you are the only human on earth
that I have yet encountered who embraces even a slight part of this.
It's a battle I gave up on.
-- E
> On Jan 23, 2016, at 4:25 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
>
> API guidelines should probably be consistent about enum cases and static let properties
>
> I’ve been naming my 'static let’s in UpperCamelCase to match the convention of enums, because I often use them the same way in code. But standard types do differently, e.g.
>
> var initialPoint:CGPoint = .zero
>
> -DW
>
>
>> On Jan 23, 2016, at 11:11 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>>
>>> On Jan 23, 2016, at 2:12 AM, Marc Knaup via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> What is the rationale behind naming enumeration cases in upper camel case?
>>>
>>> Follow case conventions: names of types, protocols and enum cases areUpperCamelCase. Everything else islowerCamelCase.
>>>
>>> let a = NSComparisonResult.OrderedSame // refers to a value, but is upper-case
>>> let b = NSDate.distantFuture // refers to a property/value, but is lower-case
>>> everything related to types (type names, protocol names, generic type parameter names) should be upper camel case
>>> everything else (function names, property names, variable names, etc.) should be lower camel case
>>> This is already the current and the proposed recommendation with enumeration cases being the only exception.
>>> Enumeration cases are not types.
>>
>> I agree. It would make enum cases feel more consistent with the rest of the language to make them lowerCamelCase.
>>
>> -Joe
>>
>> _______________________________________________
>> 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/20160123/906f4830/attachment.html>
More information about the swift-evolution
mailing list