Pitch: an Official Style Guide and Formatter for Swift

(Pierpaolo Frasa) #244

I'm very torn on this issue.

First of all, I don't think that minor differences in style are a bad thing (TM) and especially for very complex codebases, the idea of everyone's code looking the same (down to the choice of using loops vs. map/reduce) seems utopian to me. That said, sometimes I have ended up working with developers that make very poor (as in, probably objectively poor) formatting choices. Sometimes, this is because the developers are still quite junior and haven't yet developed enough aesthetic sensitivity and/or are somewhat overwhelmed having to grapple both learning the language and the style; sometimes, it's because they're technically brilliant but somewhat disorganised minds; etc.

That's why I think that making it easier to integrate some automated style guide check is very useful, especially for somewhat bigger and more diverse teams; otherwise we have to either live with very weird code being checked in or with style arguments in PRs (which I think is the wrong thing to do, in PRs).

Now, there are already tools that help with this, for example SwiftLint (which we already use). But currently, it seems to be somewhat too limited / not comprehensive enough. Also, there's issues with XCode's auto-formatting—one pet peeve of mine is the indentation of else in multi-line guards (which, in our codebase, are extremely frequent).

I'm not really sure we need a new tool. I'm also not sure we need a one-size-fits-all code style (others have mentioned how complex the Swift language is as opposed to e.g. Go, and I also think that due to the kind of problem domain you're working on you might use certain features more than in most codebases, like multi-line guards). What I do think we'd need is a better way to get started with things like SwiftLint (e.g. integration into XCode), making SwiftLint more powerful (so it can also check some formatting choices and auto-correct them, etc.). It's fine, IMHO, to have some "starter" code style that can get people (especially newbies) started very quickly, but I would also argue that it should be made configurable.

4 Likes
(Pierpaolo Frasa) #245

First of all, this ignores that for a number of reasons XCode is still the default IDE used by almost everybody (head over to the r/swift subreddit, and you'll see people talk about XCode apps/projects rather than Swift, for newbies it's not at all clear that there is a distinction), and that XCode isn't really that open to plugins and configurability. Personally, I'm using CLion (for server-side development), but it's far from perfect either, and I suspect that VSCode developers etc. will say the same thing; and even then, I can't get my team members to switch to my IDE of choice.

Second, this is not just about solo developers, but about mid-size to large teams where maybe a senior developer would like to make style decisions for the whole codebase that should then be adopted by the team in general; telling every developer how to configure their IDE in a very complicated way doesn't seem all that feasible. If there was some sort of widely accepted tool together with some tutorial articles à la "how to set up tool X with IDE/editor Y", it would be much better.

3 Likes
(Preston Sumner) #246

In my opinion, style choices that fall within a sane spectrum don't matter much, and consistency is more important. When it comes to conventions, I'm willing to sacrifice my freedom to argue about superficialities--I don't actually care where a brace goes as long as it's always in the same place so it can properly serve as a visual cue. I liken it to the standardization of manuscript and screenplay formats in the writing world, which are handled automatically by word processors so that everyone follows the same visual cues when scanning the page.

13 Likes
(Suryakant) #247

Agree there should be Official style guide and formatter for swift language. But i think there should be also a option to enable this enforcement or not. So that it can be backward compatible and safe for demo projects

(アンドレカンドレ) #248

developers are not, but corporations are, and for swift to be adopted more readily and reliably in corporations, a style guide or auto-formatter is important, because many large corporations need 1. coordination between teams and 2. hire lots ahem “interchangeable” team members.
————
my 2c is that i would prefer this to be able to be tightly integrated in the ide, that way as i type it’s already formatted correctly (pre-commit hooks in git is super aggravating and is the bane of my life... ) and format on save is also quite jarring...

1 Like
(David) #249

This is why I think the solution is not to focus on style but rather on libraries for interacting with the AST. This is what an editor or IDE would need to be able to format and print code as it is input. This is also why I think the core project should own this tooling. To be great, it needs intimate connection to the language in a way that 3rd party tooling just doesn’t achieve. Any such libraries and tools will naturally need a default representation when printing the tree. So keep the default light and focus efforts on an interface that e.g. Xcode can integrate at a code level with so we don’t have silly pre-commit or on-save action hooks that rewrite entire files...

3 Likes
(Pierpaolo Frasa) #250

XCode doesn't even have SPM support. I'm curious where people think this magic IDE integration is going to come from.

3 Likes
(Jacob Williams) #251

In addition to that and with regards to the following:

With the new Swift LSP transition that is underway I don't see what advantage the core project even has over any 3rd party tool that could be developed.

2 Likes
(Neil Tiffin) #252

If all this means is enforcing the bad choices that Xcode makes for formatting, then no I do not believe it is valuable. 3rd party tools exist because Xcode is so bad. With that said, I do use Xcode formatting frequently for reindenting loops and if statements, but I cannot, in any circumstance, use it for a complete source file.

(Jacob Williams) #253

I hope this wouldn't enforce Xcode's bad choices. There's a lot of people that have gripes with Xcode's formatting. I think this would ideally be independent of Xcode since this would occur at the language level instead of the IDE level. It would likely function similar to the 3rd party tool; being a separate executable that could be ran as a separate build stage (or on file save or whenever).

But this is just a pitch and all this would need to be proposed and accepted first.

2 Likes
(William Jon Shipley) #254

Like many of you, I think Swift should 100% have an official style assuming it’s exactly my style, and if not I don’t think it should.

16 Likes
(Chris Lattner) #255

Haha, such honesty :slight_smile:

-Chris

5 Likes
(Xiangyu Sun) #256

YES(to we can move on to the work :slight_smile: )
As the same time I support to make it optional.

How do we ever know if it's good or bad if we never do it. But I know for sure it will save time and cost for people who know the pain of war of style(ego). So they can use the resource on something more important(etc. code design).

(Ted Kremenek) #257

Review Started

There is now an official review for this proposal:

Thank you to everyone who contributed to this thread in the pitch phase. That feedback will be incorporated into the final review. Note that the proposal has been revised based on feedback on this thread. Please continue further discussion on the review thread.

5 Likes
(Ted Kremenek) closed #258