[Discussion] Naming directives


(Anton Zhilin) #1

Currently, Swift follows all-lower convention for #-directives. We haven't
discussed it much, but just derived it from a few existing directives we
have.
Now people invent new directives: #setline, #fileliteral. Now it becomes
obvious that lowercase just breaks down for anything long enough. CamelCase
is much more clear (read distinguishable) than thatlowercasemess. Compare:

#colorliteral vs #colorLiteral
#imageliteral vs #imageLiteral
#setline vs #setLine

Directives read like functions:

#fileLiteral(resourceName: "name")
#setLine(1)
#available(iOS 8.0, *)

One may say that their arguments aren't really Swift values and objects,
but that's why they are directives, after all.

#if stands out a bit, but the change will not affect it.


(Jordan Rose) #2

I agree that camel-case is more readable than all-lowercase, although the only all-lowercase names currently are '#dsohandle' (very rarely used) and '#elseif' / '#endif'. I also have a knee-jerk reaction against '#endIf'; somehow '#EndIf' doesn't seem quite as bad to me.

I can see the argument for naming the expression-like directives like values. I'm not sure whether it's necessary that the non-expression-like directives follow the same naming convention. Something to explore.

Jordan

···

On Feb 25, 2016, at 11:06, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

Currently, Swift follows all-lower convention for #-directives. We haven't discussed it much, but just derived it from a few existing directives we have.
Now people invent new directives: #setline, #fileliteral. Now it becomes obvious that lowercase just breaks down for anything long enough. CamelCase is much more clear (read distinguishable) than thatlowercasemess. Compare:

#colorliteral vs #colorLiteral
#imageliteral vs #imageLiteral
#setline vs #setLine

Directives read like functions:

#fileLiteral(resourceName: "name")
#setLine(1)
#available(iOS 8.0, *)

One may say that their arguments aren't really Swift values and objects, but that's why they are directives, after all.

#if stands out a bit, but the change will not affect it.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #3

Exceptions from guidelines probably can happen, given an argumentation. In
attributes, @NS- and @IB- things for compatibility with Objective-C. Here,
#elseif for analogy with "else if" in usual Swift. #elseIf also feels odd
to me.
Can #end be a better name for #endif?
Anyway, I think I won't create a proposal draft until the proposals
containing mentioned directives get accepted.


(Howard Lovatt) #4

Camel-case, mild preference for lower since keywords are lower

···

On Friday, 26 February 2016, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:

I agree that camel-case is more readable than all-lowercase, although the
only all-lowercase names currently are '#dsohandle' (very rarely used) and
'#elseif' / '#endif'. I also have a knee-jerk reaction against '#endIf';
somehow '#EndIf' doesn't seem quite as bad to me.

I can see the argument for naming the expression-like directives like
values. I'm not sure whether it's necessary that the non-expression-like
directives follow the same naming convention. Something to explore.

Jordan

> On Feb 25, 2016, at 11:06, Антон Жилин via swift-evolution < > swift-evolution@swift.org <javascript:;>> wrote:
>
> Currently, Swift follows all-lower convention for #-directives. We
haven't discussed it much, but just derived it from a few existing
directives we have.
> Now people invent new directives: #setline, #fileliteral. Now it becomes
obvious that lowercase just breaks down for anything long enough. CamelCase
is much more clear (read distinguishable) than thatlowercasemess. Compare:
>
> #colorliteral vs #colorLiteral
> #imageliteral vs #imageLiteral
> #setline vs #setLine
>
> Directives read like functions:
>
> #fileLiteral(resourceName: "name")
> #setLine(1)
> #available(iOS 8.0, *)
>
> One may say that their arguments aren't really Swift values and objects,
but that's why they are directives, after all.
>
> #if stands out a bit, but the change will not affect it.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.


#5

For the #-directive, like for the @-attribute, I see them a language keyWords which I believe to be better in all lowerCase; maybe I’m just lazy and hate typing upperCases letters on my keyBoard. But mainly, I think these upperCase letter in the middle of what I see as a single "common" word get distracting (its worst for the shorter one like setline). I know that Swift aims for one golden case rule to rule them all, but I do think that API/library words versus compiler words could differ a bit on that regards.

Neither of these colorliteral, imageliteral, setline are any harder to read that some of the few german composed words I remember from way back when I try to learn it: Krakenschwester, Tageslichtprojektor.

In the end, it is just about how you read it and visualize it. I see #colorliteral and #imageliteral as two distincts entities (a colour thingie and image thingie), not two variant of single #literal concept which can contains either a colour or an image.

Dany

···

Le 25 févr. 2016 à 14:06, Антон Жилин via swift-evolution <swift-evolution@swift.org> a écrit :

Currently, Swift follows all-lower convention for #-directives. We haven't discussed it much, but just derived it from a few existing directives we have.
Now people invent new directives: #setline, #fileliteral. Now it becomes obvious that lowercase just breaks down for anything long enough. CamelCase is much more clear (read distinguishable) than thatlowercasemess. Compare:

#colorliteral vs #colorLiteral
#imageliteral vs #imageLiteral
#setline vs #setLine

Directives read like functions:

#fileLiteral(resourceName: "name")
#setLine(1)
#available(iOS 8.0, *)

One may say that their arguments aren't really Swift values and objects, but that's why they are directives, after all.

#if stands out a bit, but the change will not affect it.


(Vanderlei Martinelli) #6

Well... I think that there is nothing wrong with the current directives
*and* attribute names being lowercase (with some exceptions for attributes
when relating to Objective-C/Cocoa support).

One of the things I dislike in Java is the @Override. First the `override`
should no be an attribute, but since it is, `@override` would be much more
pleasant.

The same goes for directives that is what is being discussed here. I vote
for lowercase.

-Van

···

On Thu, Feb 25, 2016 at 5:31 PM, Антон Жилин <swift-evolution@swift.org> wrote:

Exceptions from guidelines probably can happen, given an argumentation. In
attributes, @NS- and @IB- things for compatibility with Objective-C. Here,
#elseif for analogy with "else if" in usual Swift. #elseIf also feels odd
to me.
Can #end be a better name for #endif?
Anyway, I think I won't create a proposal draft until the proposals
containing mentioned directives get accepted.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution