Code style serves many masters. Part of the code's intent is clarity for the person who is writing it; part of the intent is clarity for the people who will read it in the future; part of it is mechanical (e.g. matching indentation style so others don't have problems); and part is purely an expression of shared aesthetic values.
Often, strict compliance to a set of rules makes it harder to achieve some of these goals. I have idiosyncratic formatting in several places, allowing the small deviation from the norm to serve the goal of clarity while at the same time having a consistent style where these issues do not matter.
So:
+1 at having a style guide that makes recommendations.
+1 at having tools that make it the default to apply these recommendations. For example: a guide that shall serve as a style guide for Xcode completions, the formatting of Swift fixits as they are presented in error messages or applied in Xcode, served via LSP as suggestions etc.
A mild rebuke at requiring strict, 100% adherence to a maximalist style that doesn't allow local clarity deviations.
±0 to requiring strict, 100% adherence to a well-thought-out set of principles that doesn't hinder the above.
543919427‰ YES
I love the experience of writing rust code, tapping ctrl+s and my code being prettified automatically. Not having to debate internally about where to split the line is nice.
Having official style guide would also be great. I don't feel strongly about most of the formatting decisions, but I love consistency.
Oh, and -1 for forcing people to use the official style. It doesn't sound nice.
I couldn't agree with Dave more. Make swift-format part of Swift? Yes, let's do. Come up with an official style guide and make it the default? Sure. Enforce that style? No x 1million.
Just to make sure we're not getting hung up on terminology, the term "enforce" in my mind means that the formatter, when run on the code, would transform it into whatever style is ratified as the official style. (And one of our open questions is whether that is one single style or whether it can be configured, and if so, to what degree.)
It sounds like some other folks might be interpreting "enforce" as "code that does not conform to the style is invalid" in the sense that the compiler wouldn't accept it. That's not what we're proposing—it's certainly a position that one could take, but I'm fairly certain it would be a non-starter.
There is nothing being suggested that would prevent anyone from just not running the formatter ever on their code. That's their prerogative.
I support a recommended style guide for Swift, and the inclusion of a swift-format tool.
If swift-format is performant enough, I think it would also be interesting to consider allowing for on-the-fly formatting via some specification that could, e.g., allow Xcode to support different viewing and saving styles, so that users could write and view code using whatever style they want, but the project would have one consistent style when viewed “raw.”
I am very happy to see this being talked about. I would be very much in favour of having a single tool that is able to format Swift code, and I feel like it shouldn't be integrated only with Xcode. I know people who use VS Code to write most of their Swift tools (I do that myself from time to time), so seeing that this project is starting out in the open is already a good step.
I also feel like if we get the Swift team to care about these tools, their quality will definitely increase. I've found a couple of bugs in the third-party solutions that are powered by SourceKit under the hood, and that's because SourceKit wasn't meant to be used in that way and the maintainers are not really checking their API changes against these tools. Using SwiftSyntax and including the tools required in the Swift project, would definitely raise the quality of the tooling in my opinion.
I spent the last couple of weeks formalising our internal Swift style guide, and trying to get most projects to adopt it. It has been difficult, and this would have been much easier if the tools were included in the IDE (or available as plugins for the most popular ones).
I think it's pretty much agreed that including a formatter in the Swift project is a good idea and I honestly would love to see this pitch move forward to its full extent: enforce the code style everywhere. Sure, people will dislike it at first, but looking at the big picture I think the time gained from formatting code manually (or with tools, those still takes times to install and integrate) is something that we should strive for. On the other side, it's also true that tools should help developers, and we don't want people to waste time in fighting the formatter all the time.
I am definitely +1 this pitch, and happy to help contribute where I can.
I am strongly in favour of this proposal. No-one is going to be forced to use a formatter (how could they be?) but the benefits of choosing to are well-stated in the proposal.
It would be amazing if this proposal is adopted. I agree with most of the feedback mentioned above - a million likes!
Besides what was already mentioned, I can offer one more take on it:
some (probably many) developers are already looking up to Apple’s native code style - in headers, open source code, Swift language guide, Xcode templates, Xcode’s auto-indentation, etc - for both Swift and Objective C.
I’ve been always doing that and encouraging my team to do the same, especially when we had 50/50 split on some style point. In the end, our code style is heavily based on “what Apple does”.
So it would be amazing to see the official style written down, and I wouldn’t expect it to end up being very different from the existing common one.
The term "official style guide", to me, sounds like we would declare the one true style (including spacing and line lengths -- do we really want to have a tabs/spaces debate on these forums?) and anyone deviating from it would need to explain themselves. So, the arguments about style will just continue in another form.
That is why I would rather focus on the tools that allow teams to determine their own destiny rather than spend any effort on attempting to make some kind of decision on what those should be for everybody -- even as a starting point. As you probably noticed, my personal opinion comes through in the way that Foundation's source is formatted. It differs pretty dramatically from the standard library.
Reformatting on commit, Xcode integration, warnings in code review -- all of those can be supported by writing the tools discussed here, and all without the need for Swift to declare what the Right Answer is.
I suspect that over time, with the presence of the tools, we could collectively learn a lot about how people format their Swift code and better standards may naturally emerge. However, I doubt that things like 2/4 and 80/100/120/unlimited will be possible to get agreement on.
I think this is a valid concern, however Go is a great case study for what happens when a language level style guide is in place. Ask any Go programmer what they think of gofmt and while they may disagree personally with some of the style choices that were made, it's almost universally seen as a positive that they don't have to make any decisions at all about style.
The result was an end to the style debates rather than prolonging them. IMO, allowing everyone to just do their own thing will never result in a cohesive community style and will end up prolonging the style disagreements forever.
I think things like indentation width and column with are the one configuration option that makes sense for an opinionated formatting tool.
Considering the amount of debates over style I've been involved in over the years I think this is a great idea, it would allow a consistent recommended style across the board.
Should there be an official style? Yes. Should there be an official formatting tool that enforces this style? Yes.
I currently use @nicklockwood's excellent SwiftFormat, and it takes the thinking out of styling my code - I just write code that reads well (and works), and the formatter decides how it should be laid out.
$ swiftc --driver-mode=swift-format --help
OVERVIEW: Swift Format Tool
USAGE: swift [options] <inputs>
OPTIONS:
-help Display available options
-in-place Overwrite input file with formatted file.
-indent-switch-case Indent cases in switch statements.
-indent-width <n> Number of characters to indent.
-line-range <n:n> <start line>:<end line>. Formats a range of lines (1-based). Can only be used with one input file.
-o <file> Write output to <file>
-tab-width <n> Width of tab character.
-use-tabs Use tabs for indentation.
I love working with Go and its automatic formatter. Also with other languages that followed Go, like Dart. Although I love Swift the most, I always miss that formatter when writing Swift. Over the years my team has integrated several tools like Swiftlint and Swiftformat, but having a fast integrated tool in the IDE is unmatched.
But the most important reason for me is that it improves contributions in open source projects: maybe it’s easier to force a format in your company, but try that with millions of open source repos. A standard formatter would make easier to contribute in several projects at once, too.
And about which style to follow... I also don’t care. But maybe we can extract some style data by analyzing the code in the compatibility suite?
This is wrapping the C++ code that is doing indentation only and is not a good base to build a proper formatter on; it would be much better to use a formatter tool written in Swift.
