SE-0250: Swift Code Style Guidelines and Formatter

Evolution Proposal Reviews
1

The review of SE-0250: Swift Code Style Guidelines and Formatter begins now and runs through April 10, 2019.

The proposal is written by @allevato and @dabrahams.

Please note that there has been significant discussion already on the pitch thread. The Core Team will incorporate feedback already on that thread when evaluating this proposal. However, note that the proposal has been revised based on feedback on that thread. It was clear from that discussion that the community was ready to move from the pitch to review stage to discuss the proposal.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via email or direct message on the forums. If you send me email, please put "SE-0250" somewhere in the subject line.

What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

  • What is your evaluation of the proposal?

  • Is the problem being addressed significant enough to warrant a change to Swift?

  • Does this proposal fit well with the feel and direction of Swift?

  • If you have used other languages with a similar feature, how do you feel that this proposal compares to those?

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thank you for contributing to Swift!

Ted Kremenek
Review Manager

32 Likes
2

I'm +1 on this proposal.

I participated a bit on the original discussion thread and felt there are so many loose ends to discuss here, which is why I loved the fact this specific proposal was just diluted down to the most important point:

This meta-proposal does not attempt to define any specific style guidelines. Its purpose is to answer the following existential question:
Should the Swift language adopt a set of code style guidelines and a formatting tool?

I feel this answer is a definite "Yes!". Whether or not it would be optional, configurable, open-source, IDE-integrated, command-line, what ever; are all details that belong later in this process in consequent proposals, as suggested above.

I feel the proposal well fits Swift's direction and solves a significant enough problem that is already well-solved in other strongly-typed languages.

I've briefed over the proposal but was involved in the original thread.

5 Likes
3

I suppose I could get behind this. I strongly believe that formatters are better than linters. Even though I have my own opinions about formatting that are not going to be universally agreed upon (tabs or GTFO), I'd rather just have a source of truth and move on to something more important.

That being said, I am pretty happy with SwiftFormat now, so I don't see a big pressing need for this, although I would assume this would be more likely to push the Xcode team to integrate with this kind of tool better.

4

I'm +1 on the proposal

I'd like Swift to have an "official" style guide and related format tool to enforce it, but I have doubts on making it "optional" or not. On one side, programming is too opinionated for us to make a style decision for everyone. I think using the same style (especially within a project) does have a lot of pros, but it should be users' ultimate decision which style(if any) to adopt. On the other side, different code styles get sometimes into our way, making collaborating more difficult, and having a single source of truth (even if we don't agree on everything) might make us spend less time arguing about styles and more time actually solving problems.

While I would love this to happen, one question arises to me: is this so important though? Seems like lately the attention has shifted a lot towards this, even though there's a lot more we could do for Swift. We should also consider that something like this already exists, so maybe this is not as urgent as it might be.

1 Like
5

  • What is your evaluation of the proposal?
    +1

  • Is the problem being addressed significant enough to warrant a change to Swift?
    Yes. I think this would be great for new users and teams.

  • Does this proposal fit well with the feel and direction of Swift?
    Yes.

  • If you have used other languages with a similar feature, how do you feel that this proposal compares to those?
    N/A

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
    Followed previous discussions.

6

Strong +1.

Yes!

Yes.

Yes, Python's PEP-8 and I love it.

Read the pitch and the proposal.

7

We are also willing to consider additional degrees of configurability.

On what basis will these be considered? Is it based on personal preference, accessibility, practicality of screen size, etc?

8

+1

I strongly believe the style guidelines and formatter should be mandatory, Ă  la Go.

4 Likes
9

+0. While I always welcome better tooling support, the wording of the proposal tilts away from “common/default style” to “official style”, which is a big deal to me. There’s nothing wrong if 60% of the community decides to standardize on a common style, but I certainly don’t want to see code that doesn’t conform to the decreed style start to be considered illegitimate.

No.

(I’m also curious that 7 people, mostly new to the forums, came here to vote in favor of this within 30 minutes of it being posted?)

N/A

Python has this, but python is also a much simpler language syntactically, so I would hesitate to transfer assumptions between the two languages.

Participated in discussion and read the proposal

8 Likes
10

Do you mean the other way around? The new version of the proposal was updated to specifically avoid phrases like "official style guide" in order to address the very sentiment you're expressing here; we don't want anyone who has different needs/preferences to feel "lesser" but we still want them to be able to benefit from the tooling.

11

The proposal text seems to imply that “not mandatory” means “the compiler will still compile code that doesn’t conform to the guidelines”. My gut feeling is that “official” will become an unspoken part of the proposal, and after a while people are just going to start calling the recommended guidelines the “official guidelines”. It does not help that many of the voters supporting this proposal are using language like official and mandatory in place of the actual proposal language. It should be updated to specifically emphasize that any such guidelines would be

  • default guidelines, not standard guidelines.
  • common styling, not recommended styling.

“recommended”, “standard”, and “official” carry v different implications compared to “default” or “common”, and a responsibly-written proposal should make that clear to avoid anything getting ratified de-facto that isn’t in the actual text.

6 Likes
12

We strived to clarify as much as possible from the previous iteration of the proposal based on the wealth of feedback in the pitch thread, with statements like this which are intended to clearly explain our position on the matter:

The use of "recommended" elsewhere in the text was deliberate. We do wish to "recommend" these code style guidelines just as Swift recommends the API Design Guidelines. That doesn't mean that people can't diverge from those if they have good reason, where "good reason" is honestly whatever they want it to mean for their project. If someone working on a personal project wants to do something completely different, great! We have no interest in stopping them or dictating anything to them.

There's nothing we can realistically do to prevent all possible misinterpretations of the text no matter how explicit we try to make it, and people will interpret words differently no matter which ones we choose. Ultimately, the proposal text has to be locked down at some point and I hope people will review it as it is written, not based on how people might hypothetically misinterpret it.

13 Likes
13

-1

Imho the proposal is neither one thing nor another:
It won't ensure consistent formatting of Swift code, and still, it would repell people who disagree with the choices made in the guide.
It's just not possible to get the best of both extremes (staying neutral vs. enforcing a single style), but it's very easy to get the worst combination.

Looking at this forum, I predict that acceptance will only lead to a myriad of endless discussions, which burn time which can be spend better.

Btw, afaics, the proposal isn't even qualified to be reviewed unless the Evolution process is changed so that an implementation isn't required anymore...

10 Likes
14

Part of the proposal is the adoption of a formatting tool into the Swift project, whose implementation is linked in the proposal: https://github.com/google/swift/tree/format

2 Likes
15

An agreement is what everyone walks out of the room feeling like they agreed to. Any organization is governed by the people in it, not what’s written on a piece of markdown. Based on the reviews so far, it seems like most people are agreeing to an official style, not a default style.

16

Huge +1. And a big thanks to the proposal authors and everyone who contributed to SwiftSyntax and the swift-format tool.

Even if this doesn't get accepted (which would be sad IMO), I hope that swift-format is open sourced separately so that those who want to benefit from it can.

4 Likes
17

+1 on a default or official style guideline + integration of such a tool into Swift.

It would solve so, so many counter-productive problems when working in large projects or with many developers.

Coding is hard as it is, so let’s make it a little bit easier. :slightly_smiling_face:

2 Likes
18

Fair, the position is clear, not disputing the clarity (just that it may be rubbing people the wrong way as the resistance is about exactly that... people may not be desiring an official Apple/ Google blesses code), but based on this I think having better tooling support so that Xcode plugins and command line tools could do the formatting job better and more easily may be a better win for the community than trying to bikeshed the “recommended” style and the repercussion it will have in the daily work life of teams... how minor or major they may be depending on the people and the team culture.

It is interesting to see if this would have any effect how many people would maintain other tools like Nick’s swiftformat, swiftlint, and others with a blessed 1st party tool on the market... unless like SPM vs Cocoapods or Carthage it cannot be used yet for some reasons (with SPM being it not being easy to use / supported for iOS projects yet).

Depending on the changes that will make your Swift-format tool be able to do its job and the other formatters being able to benefit from it or not it would be a -1 to +0.5.

1 Like
19

I'm really thankful for this work, and I very much support having linters, formatters and similar tooling — but I can't see the benefit of "blessing" a particular tool.
Actually, I think this won't actually help, but rather slow down development.

4 Likes
20

+1 on having a built-in, works out-of-the-box formatter that ONLY uses the recommended style (just like the highly liked gofmt utility), but -2 on having a style guide that is not mandatory.

Overall, -1.

If the style/format is not mandatory, then why even bring it to the table for discussion? I feel like only the people that will use it are those who agree with all its decisions or those who are forced to use it in order to contribute to swift. The proposal states as much when it says:

A tool that is not configurable only works for users
who are completely satisfied with the defaults.
That quote is specifically talking about making the formatter configurable, which I also disagree with.

If there's just going to be another configurable formatting tool then I am strongly opposed to diverting more resources when there are perfectly capable tools already out there. Those who really care will find them, install them, and configure them. Those who don't care won't. I really think it's just that simple. The current status quo is a valid thing to consider.

I know that if I'm not forced to change my coding style then I certainly won't bother with it. Sure there may people who end up referencing the recommended guidelines as though they were official guidelines, but the majority of users will likely never need to even know about the recommended style if they don't absolutely have to follow it.

The proposal states:

We have chosen not to do so given that Swift is a well-established language.

I don't think that it's "too late" to have a mandatory style guide just because swift isn't a new language. There have been plenty of changes that resulted in widespread fallout that were done regardless and I wouldn't be surprised if there were further changes in the future that resulted in significant changes/breakage. Much of this has been/will be done in a multi-phase deployment. ie: begin with deprecation warnings in the next version, then in failures with the following version. I see no reason why this couldn't be the same. Start by warning people that their code doesn't follow the "official" guidelines. Then in the next version make it a compilation failure.

Also, if there's an associated formatting tool then it would automatically convert everyone's code to the recommended format anyways right? So why couldn't we make it an official/mandatory guide? Going forward there would be a learning curve while everyone adjusts to the changes, but it wouldn't take that long for everyone to learn/accept them.

Without the format being enforced I view the meat of the proposal as being about making a "blessed" formatter. No one really cares if the backend is built using the new SwiftSyntax if it doesn't work as well as the competition. SwiftFormat is 3 years in the making and a new tool would take years to catch up to where it's at today, regardless of what backend powers it. I restate my opinion from the pitch phase that the people who really care about enforcing their preferred style are going to evaluate the tools available and do whatever it takes to get it installed/configured to their liking.

Yes. The motivation stated in the proposal is entirely valid, I just disagree with the proposed direction.

I'm on the fence here. While swift is opinionated in some aspects, it largely tries to let people do things how they want to do them (however horrible that may be). I think it would be nice to have an "official" (not just recommended) style guide/best practices. Whether or not this is something that swift should become opinionated about is not something I feel qualified to say.

I use PEP8 formatting tools when coding in python and the gofmt tool is highly liked. I wish swift would make the leap to require an "official" format for all the reasons why this is being proposed in the first place. It's a real pain to read different code soemtimes. Consistency is a really nice thing and I'm willing to sacrifice my own preferences to make it easier for anyone to read swift code anywhere.

9 Likes