Pitch: an Official Style Guide and Formatter for Swift


#202

Exactly this. One thing to consider is that some individuals have visual impairments and need some extra spaces in the code they write to be able to visually parse it. If you make a strictly enforced style guide agreed upon by the majority then you will almost certainly leave those with accessibility challenges out in the cold suffering.

One guy I worked with needed the space after "(" and before ")" in order to be able to visually parse the code on screen, even with the best programming fonts and largest reasonable font size he could use.

So:

So, I'm in favor of having an auto-formatter. Just please make sure that I can tweak it and turn on or off things that I want.

What we want is readable code, and everyone tends to have slightly different definitions of what that means.

Agreed. A formatter that can take a simple rules file and apply those rules to code is the best solution. Include a "standard" rules file if you like. Organizations can then customize that rules file to accommodate the individuals on their hopefully diverse team.


(Xiaodi Wu) #203

That's not a matter of style or formatting. It is a matter of correctness of code; enumerated() does not return indices.

...and therefore it is a matter of style and formatting. One of these is idiomatic, and the other is not; there is no reason not to standardize and thereby eliminate the matter altogether.

Yes, indeed, style and formatting are issues that people deal with. Most of the readers and writers of code are people, not colons.


(Lance Parker) #204

Right, this is what a linter is for.


(Preston Sumner) #205

I have no problem using different conventions depending on the language I'm writing at the moment. For example, the Allman style prevails in the C# world. These conventions are a useful flag for me to adapt my thinking to a particular language.

As a result, I'm in favor of a style guide and formatter for Swift. Speaking only for myself, configurability isn't a concern--if the default style differs from the code I've written before, I'll update my personal style to match.


(David Hart) #206

Your first example feels more like the realm of a linter. It would be awesome to have a officially supported linter :heart: but this is a different discussion. The formatter should only bother about whitespace characters and has value in its own right.


(Nick Keets) #207

I find @xwu's point about keywords a very good one. What about the (imaginary) vocal minority that are using custom preprocessors in order to use fn instead of func? Is it pure imperialism that func has been set in stone and there is no configuration option to change it? I'm sure they have very good reasons to prefer fn over func.


(^) #208

well, i suspect a lot of people use them interchangeably given poor knowledge of Swift’s Sequence/Collection hierarchy, and when used on Arrays, they are interchangeable, so it is a matter of style in that context. Those of us who use generics prefer zip on indices for consistency between Array and ArraySlice, but ultimately that is a style preference, for Array loops, since the code is functionally identical. But this is all very specific and not really relevant to the thread so i’ll stop.

not to shade the effort here at all, but in the spirit of standardization, it’d be nice if we had the same enthusiasm for standardizing currency/textbook types like RGBA, Vector, Matrix, Quaternion, Queue, RBTree, etc. Who’s in? (on a different thread of course)

well, count me in for the linter effort <13

i honestly probably will not use this style guide or formatting tool, though i have no objection to it being organized here. I (like others) just ask that we call it the Default style guide and not the “Official style guide” to emphasize it as a starting point rather than a prescription.

I believe the formatting tool that comes with it should be customizable, but customizations should not be called ‘Default style’, in order to maintain the standardization and consistency (and thus the whole point) of the default style rules.

In other words, we should not have a default-style-formatter, but rather just a style-formatter that is capable of applying the --preset=default style, along with downloadable, team-defined, and user-defined presets. I suggest this only because I suspect much of the code implementing a default style formatter could also be repurposed to apply other styles, and offers a win-win between those who want to preserve the uniformity of the default style, and those who want to use their own presets.

this is a pretty out-there example. i don’t think anyone is going through the effort to preprocess fn to func just so they can spell function declarations differently. I only recently bothered with getting an automated gyb preprocessor up and running in one of my build systems. Varying colon styles on the other hand are very much a thing.


(Cory Benfield) #209

What I do not understand, and would love to see answered by someone in this camp, is why posters in favour of a configurable tool believe that there should be an official language formatter.

As far as I can see, the desire to make the linter configurable boils down to a sentiment of "I am in favour of automated style enforcement, so long as we enforce my style". And that's fine, I get it. But if you want that today you can already have it: there are many Swift style tools already in place, as well as the new one proposed here. This is already the status quo.

What no-one has clearly elucidated in my view is why it is useful to have an official tool that does not have opinions about what the code should look like. So my questions to anyone in favour of a configurable official tool is simple: what utility is provided by such a tool that is not provided by the open source ecosystem today?


(Nick Keets) #210

To me having a pationate preference over func foo() vs fn foo() seems much more substantial than let x: Int vs let x:Int. Why having one not be configurable is ok, while for the other is a travesty?


(^) #211

because fn foo() has never compiled with swiftc, whereas let x:Int has always compiled with swiftc.


(Nick Keets) #212

So can I count on your support for my pitch to make func keyword configurable?

That would be absurd right? Why make people have to choose over 2 different styles?


(^) #213

If func and fn had been interchangable since, say, 3.0, then i would, but they’re not, so i won’t.


(Boris Triebel) #214

These people who look for an authoritarian single style should get together and create a tool and use it among themselves. Please stop your efforts to take away my freedom and force your opinions on me. Seriously. What is this discussion.


(Gwendal Roué) #215

There is another way to look at those two opposed forces.

For each configuration option you add, you multiply the number of configurations the tool has to support. This combinatorial explosion makes the tool output less predictable, and the quality of the code it generates more difficult to assert, maintain, and preserve in the long run.

A sufficient amount of work could overcome those difficulties, of course. But we need some people to actually provide this work. This question is at the root of the configuration debate. It's still very abstract at this stage. It will become more precise sooner or later.

I'll personally push for the highest possible Quality. If configurability has to suffer on the way, I personally do not care. This is my point of view, I am able to defend it, and I am sure I will find support. And I do not have anything against configuration itself.


(Boris Triebel) #216

If this formatter turns out to be either intentionally crippled or seriously limited because of implementation complexities for which not enough effort can be mobilized (because of people who actively work against it because of their religious belief in mono culture code style) then this whole effort will be end up as a really sad story.


(Morten Bek Ditlevsen) #217

I love this pitch, and I also love this discussion.
Initially, my thought was:
Great idea, guidelines will be most welcome - they could at the very least be used for inspiration. But if a tool is made it should be customizable to my needs.

After reading a lot of arguments in this thread, I now realize that my own style and company style are still just arbitrary choices (helped along the way by great tools such as SwiftLint).
The purpose of these styles are readability and consistency.
If an official style guide and accompanying tool would impose a style on me - with no or few options for configuration, I would be just as happy (once I adjusted to the style).

So now I am totally on the side of those who argue for a common style. The fewer choices I or my team have to make, the better. :slight_smile:


(Nick Keets) #218

There is already a tool with many configuration options that you can use today: https://github.com/nicklockwood/SwiftFormat

Or not, you are free to exercise your freedom of ignoring it. Even gofmt is completely optional, I'm sure Go programmers exist that are sticking it to the Man and are not using it.


(Boris Triebel) #219

Nick, thats my point: I hope we all will not be limited in our options to "one size fits all" vs "ignoring it". I hope we can have a powerful tool that is fully integrated and officially supported for all of us.

And as for the Go reference: If Go had more complex syntax - like Swift has - and legacy APIs with sizable function signatures - like Swift on Apple Platforms has - it surely would be a different story there, don't you think.

I know from experience with Dart that even though autoformat is obviously often super nice (like the one AppCode had when i used it years ago) there a significant amount of situations where the autoformat in Dart just fucks up the readability of your code.


(Cory Benfield) #220

Why? What would be different in this hypothetical to using SwiftFormat today?


(Boris Triebel) #221

Plus the fact that it is different to have "nothing" vs "this useful 3rd party tool, even though its not fully integrated" vs. "the official tool" that provides the "default style" most likely being nicely integrated into the tooling vs "this other 3rd party tool that people used before the official formatter you can still use if you really want" (or "stick it to the Man, as Nick put it so colorful : )

Adding: To make it clear what my idea of a good solution is: Everything i said before plus obviously having an officially announced preferred default style that is set as default setting BUT can be super easily changed to "OtherCommonStyleB" configuration and "Custom" with everything that IntelliJ IDEs offer plus anything else we might want.

And i don't see a good reason and have not heard a convincing argument to not aim for that.