[Discussion] Design guideline rule for `:`


(Adrian Zubarev) #1

Should there be a design guideline rule for colons : in Swift?

I see people doing things like this:

protocol A : B {}

// VS.

protocol A: B {}
func foo<T : A>() -> T { … }

// VS.

func foo<T: A>() -> T { … }
var value : Type

// VS.

var value: Type
[key1 : value1, key2 : value2]

// VS.

[key1: value1, key2: value2]
I prefer the second style, where there is no whitespace between lhs and the : symbol and there is also a whitespace after :. Example: something: somethingElse

···

--
Adrian Zubarev
Sent with Airmail


RFC: Space or not to space
(Dave Abrahams) #2

The standard library uses " : " for conformances and inheritance, and
": " for type annotation. FWIW.

···

on Wed Jun 22 2016, Adrian Zubarev <swift-evolution@swift.org> wrote:

Should there be a design guideline rule for colons : in Swift?

I see people doing things like this:

protocol A : B {}

// VS.

protocol A: B {}
func foo<T : A>() -> T { … }

// VS.

func foo<T: A>() -> T { … }
var value : Type

// VS.

var value: Type
[key1 : value1, key2 : value2]

// VS.

[key1: value1, key2: value2]
I prefer the second style, where there is no whitespace between lhs
and the : symbol and there is also a whitespace after :. Example:
something: somethingElse

--
Dave


(Ben Rimmington) #3

The standard library team (and Xcode generated interfaces) chose the first style for inheritance and where clauses (using the colon like an infix operator).

The documentation team chose the second style, in "The Swift Programming Language" book, and in their WWDC presentation <https://developer.apple.com/videos/play/wwdc2016/404/>.

-- Ben

···

On 22 Jun 2016, at 12:40, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Should there be a design guideline rule for colons : in Swift?


(Charlie Monroe) #4

I was always wondering what's the preferred way. Xcode generates the second version for classes and even the stdlib is using the first version (space before and after colon) for protocol conformation/inheritance, though I prefer the second one.

IMHO the guideline doesn't necessarily be uniform for all cases - e.g. in case of vars, the preference can be different than with the inheritence.

···

On Jun 22, 2016, at 1:40 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Should there be a design guideline rule for colons : in Swift?

I see people doing things like this:

protocol A : B {}

// VS.

protocol A: B {}
func foo<T : A>() -> T { … }

// VS.

func foo<T: A>() -> T { … }
var value : Type

// VS.

var value: Type
[key1 : value1, key2 : value2]

// VS.

[key1: value1, key2: value2]
I prefer the second style, where there is no whitespace between lhs and the : symbol and there is also a whitespace after :. Example: something: somethingElse

--
Adrian Zubarev
Sent with Airmail

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


(Haravikk) #5

This is an interesting thing to consider, as the current auto-complete seems to favour whitespace on both sides, but I actually use it differently depending upon context.

For specifying type I use no whitespace, but for inheritance/conformance I use whitespace on both sides, so for me it's:

  protocol A : B {}
  func foo<T:A>() -> T { … }
  var value:Type
  [hey1:value1, key2:value2]

Not really able to give an objective reason why though, it just feels more natural to me this way, I suppose because the separation is useless on a type declaration to avoid creating noise around the type name itself, but everywhere else I just prefer the more compact form.

···

On 22 Jun 2016, at 12:40, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Should there be a design guideline rule for colons : in Swift?

I see people doing things like this:

protocol A : B {}

// VS.

protocol A: B {}
func foo<T : A>() -> T { … }

// VS.

func foo<T: A>() -> T { … }
var value : Type

// VS.

var value: Type
[key1 : value1, key2 : value2]

// VS.

[key1: value1, key2: value2]
I prefer the second style, where there is no whitespace between lhs and the : symbol and there is also a whitespace after :. Example: something: somethingElse

--
Adrian Zubarev
Sent with Airmail

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


(Vladimir) #6

Good question. I also asked myself if there is such guideline.
I thought we have some kind of guideline, as parameters in methods/funcs in Swift has `func foo(param: Type)` format, not 'func foo(param : Type)'. So for myself I decided that I should follow this syntax anywhere I need to place `:`.

···

On 22.06.2016 14:40, Adrian Zubarev via swift-evolution wrote:

Should there be a design guideline rule for colons |:| in Swift?

I see people doing things like this:

>protocol A : B {} // VS. protocol A: B {} |

>func foo<T : A>() -> T { … } // VS. func foo<T: A>() -> T { … } |

>var value : Type // VS. var value: Type |

>[key1 : value1, key2 : value2] // VS. [key1: value1, key2: value2] |

  * I prefer the second style, where there is no whitespace between lhs and
    the |:| symbol and there is also a whitespace after |:|. Example:
    >something: somethingElse|

--
Adrian Zubarev
Sent with Airmail

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


(Brandon Knope) #7

This is one of those things that *could* have a guideline, but it still wouldn't stop people from doing it their own way

···

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


(Leonardo Pessoa) #8

Guidelines or not I'm sticking to the second form. It looks more elegant to me.

L

···

On 22 June 2016 at 09:42, Ben Rimmington via swift-evolution <swift-evolution@swift.org> wrote:

On 22 Jun 2016, at 12:40, Adrian Zubarev via swift-evolution > <swift-evolution@swift.org> wrote:

Should there be a design guideline rule for colons : in Swift?

The standard library team (and Xcode generated interfaces) chose the first
style for inheritance and where clauses (using the colon like an infix
operator).

The documentation team chose the second style, in "The Swift Programming
Language" book, and in their WWDC presentation
<https://developer.apple.com/videos/play/wwdc2016/404/>.

-- Ben

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


(Adrian Zubarev) #9

I follow exactly the same flow.

Even if this is my personal preference, I do not like x : y at all at any corner of the language, just because it does look somehow strange to me.

// This looks much clearer to me
type TypeName: BaseType {
     
    var value: SomeType
     
    func generic<T: BaseType>(dictionary: [String: T]) { … }
}

// Compared to this
type TypeName : BaseType {
     
    var value : SomeType
     
    func generic<T : BaseType>(dictionary : [String : T]) { … }
}

···

--
Adrian Zubarev
Sent with Airmail

Am 22. Juni 2016 um 13:50:44, Vladimir.S (svabox@gmail.com) schrieb:

Good question. I also asked myself if there is such guideline.
I thought we have some kind of guideline, as parameters in methods/funcs in
Swift has `func foo(param: Type)` format, not 'func foo(param : Type)'. So
for myself I decided that I should follow this syntax anywhere I need to
place `:`.

On 22.06.2016 14:40, Adrian Zubarev via swift-evolution wrote:

Should there be a design guideline rule for colons |:| in Swift?

I see people doing things like this:

>protocol A : B {} // VS. protocol A: B {} |

>func foo<T : A>() -> T { … } // VS. func foo<T: A>() -> T { … } |

>var value : Type // VS. var value: Type |

>[key1 : value1, key2 : value2] // VS. [key1: value1, key2: value2] |

* I prefer the second style, where there is no whitespace between lhs and
the |:| symbol and there is also a whitespace after |:|. Example:
>something: somethingElse|

--
Adrian Zubarev
Sent with Airmail

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


(Charlie Monroe) #10

It would, if Xcode finally had some formatting tools or linters, like other IDEs have either on their own (AppCode, ...) or in form of 3rd party tools (StyleCop). As much as I dislike C#, when you look at C# code from various repos, it's mostly uniform when it comes to code-style since VS automatically changes some formatting for you, enforcing code-style conventions declared by Microsoft - e.g. brackets on a new line, etc.

If there were written code-style conventions that Xcode would be enforcing by default, it would force most people to code by the conventions.

···

On Jun 22, 2016, at 3:36 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

This is one of those things that *could* have a guideline, but it still wouldn't stop people from doing it their own way

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

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


(Adrian Zubarev) #11

The whole guideline won’t stop people from writing crappy code, you’re not even forced to read it. :smiley:

···

--
Adrian Zubarev
Sent with Airmail

Am 22. Juni 2016 um 15:36:47, Brandon Knope (bknope@me.com) schrieb:

This is one of those things that *could* have a guideline, but it still wouldn't stop people from doing it their own way

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


(Adrian Zubarev) #12

I’d love to see something like this happen to Xcode. I’m curious if we could write an extension for Xcode 8 to refactor code to at least some of the conventions.

···

--
Adrian Zubarev
Sent with Airmail

Am 22. Juni 2016 um 15:43:44, Charlie Monroe (charlie@charliemonroe.net) schrieb:

It would, if Xcode finally had some formatting tools or linters, like other IDEs have either on their own (AppCode, ...) or in form of 3rd party tools (StyleCop). As much as I dislike C#, when you look at C# code from various repos, it's mostly uniform when it comes to code-style since VS automatically changes some formatting for you, enforcing code-style conventions declared by Microsoft - e.g. brackets on a new line, etc.

If there were written code-style conventions that Xcode would be enforcing by default, it would force most people to code by the conventions.

On Jun 22, 2016, at 3:36 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

This is one of those things that *could* have a guideline, but it still wouldn't stop people from doing it their own way

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

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


(Erica Sadun) #13

I don't believe these rules have a place in the API guidelines, which are meant to address how Swifty APIs should be constructed for consumption. Style rules are best addressed by in-house style guides. I've personally adopted left-magnetic colons. This follows the Docs team style. The stdlib folk appear to use floating colons for protocol conformance.

As for Xcode, the new code editor extensions provide exactly this kind of functionality.

-- E

···

On Jun 22, 2016, at 8:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’d love to see something like this happen to Xcode. I’m curious if we could write an extension for Xcode 8 to refactor code to at least some of the conventions.


(Charlie Monroe) #14

I’d love to see something like this happen to Xcode. I’m curious if we could write an extension for Xcode 8 to refactor code to at least some of the conventions.

I don't believe these rules have a place in the API guidelines

No, not API guidelines per se, but code-style guidelines. I think for the sake of a more unified code-style, given the team's strong position on not allowing any language dialects, I'd suggest something like this being put together. (Yes, I understand that a language dialect is something different, but the point is that there is a strong feeling about a unified languaged.)

When you look at various code in ObjC (StackOverfow, Github), the code styles vary incredibly and it's a mess, looking at some code gives you a headache because it is obvious that the person who wrote it came from C# environment. Yes, it's up to the project's team to decide on some minor things (e.g. whether to go by the 80-char per line limit, use explicit self, etc.), but the major things, such as placement of brackets, colons, spaces between them, etc. should be standardized.

Because currently, as Ben has pointed out, the standard library has a different code-style than the Swift Programming Language or the WWDC presentation and it will diversify over the time.

I kind of really like what Microsoft has done with C# - their coding conventions are out there, clear and precise.

https://msdn.microsoft.com/en-us/library/ff926074.aspx?f=255&MSPPError=-2147217396

You may ask why would one care? Aside from me being kind of a nitpicker in this area, this is nice when you share code between projects - you have a single code-style even if you share the code.

···

On Jun 22, 2016, at 5:07 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 8:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

, which are meant to address how Swifty APIs should be constructed for consumption. Style rules are best addressed by in-house style guides. I've personally adopted left-magnetic colons. This follows the Docs team style. The stdlib folk appear to use floating colons for protocol conformance.

As for Xcode, the new code editor extensions provide exactly this kind of functionality.

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


(Adrian Zubarev) #15

True story, I know someone who’s from C# background and I’m looking at swift code that looks like this all the time T_T:

class SomeName
{
    private var _variableName : String!;
    private var _optionalName : SomeType?;
     
    func notAnInitializer()
    {
        _variableName = "ugly code";
         
        if _optionalName != nil
        {
            _optionalName!.doSomething();
        }
        else
        {
            _optionalName = SomeType();
            _optionalName!.doSomething();
        }
    }
}
This is embarrassing and ugly.

I’d rewrite this to:

class SomeName {
     
    private var _variableName: String
    private var _optionalName: SomeType?
     
    func notAnInitializer() {
         
        self._variableName = "ugly code"
         
        if self._optionalName == nil {
             
            self._optionalName = SomeType()
        }
         
        self._optionalName?.doSomething()
    }
}
My personal preference is to leave an empty line at the top (for readability from my personal prospective) and I do prefer self. for clarity what I’m accessing and from where it comes from.

···

--
Adrian Zubarev
Sent with Airmail

Am 22. Juni 2016 um 17:21:49, Charlie Monroe (charlie@charliemonroe.net) schrieb:

On Jun 22, 2016, at 5:07 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 8:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’d love to see something like this happen to Xcode. I’m curious if we could write an extension for Xcode 8 to refactor code to at least some of the conventions.

I don't believe these rules have a place in the API guidelines

No, not API guidelines per se, but code-style guidelines. I think for the sake of a more unified code-style, given the team's strong position on not allowing any language dialects, I'd suggest something like this being put together. (Yes, I understand that a language dialect is something different, but the point is that there is a strong feeling about a unified languaged.)

When you look at various code in ObjC (StackOverfow, Github), the code styles vary incredibly and it's a mess, looking at some code gives you a headache because it is obvious that the person who wrote it came from C# environment. Yes, it's up to the project's team to decide on some minor things (e.g. whether to go by the 80-char per line limit, use explicit self, etc.), but the major things, such as placement of brackets, colons, spaces between them, etc. should be standardized.

Because currently, as Ben has pointed out, the standard library has a different code-style than the Swift Programming Language or the WWDC presentation and it will diversify over the time.

I kind of really like what Microsoft has done with C# - their coding conventions are out there, clear and precise.

https://msdn.microsoft.com/en-us/library/ff926074.aspx?f=255&MSPPError=-2147217396

You may ask why would one care? Aside from me being kind of a nitpicker in this area, this is nice when you share code between projects - you have a single code-style even if you share the code.

, which are meant to address how Swifty APIs should be constructed for consumption. Style rules are best addressed by in-house style guides. I've personally adopted left-magnetic colons. This follows the Docs team style. The stdlib folk appear to use floating colons for protocol conformance.

As for Xcode, the new code editor extensions provide exactly this kind of functionality.

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