For example, in older Swift compiler versions there was a bug where optional properties had to be explicitly initialized to nil, otherwise the automatic Codable conformance could not be synthesized. The seemingly superfluous initialization triggered the redundant_optional_initialization rule, but auto-correcting it would break the build in those older Swift versions. I can understand there are ways around it, but our toolchain is brittle enough as it is, which is why I don’t feel comfortable having the linter change my code in non-trivial ways automatically.
Solving that one actually involves having a proof of P!=NP, so you're actually getting 2 million dollars (one for this one and one for that one)
I think someone solving the NP complexity related questions would get three more zeros. 
I don't even want guidelines. I want an unconfigurable formatting oracle: Everyone's code goes in, uniformly formatted code comes out.
I fully expect to dislike large parts of the automatic style. But I've been convinced that the advantages gained by a consistent style, consistently applied, outweigh my personal foibles. "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
8 Likes
Sure. I am highly doubtful that kind of formarter would come out of the swift community. Swift Formater comes close to what you want. To me I rather have a per codebase formatter config.
+1. I expected to hate this when I started learning Go. I grew to love it. It's absolutely true that it's nobody's favorite, until you have to read someone else's code.
(I would also love a tool that threw a warning if there were unused imports.)
This is one of the reasons I dislike Go. Language style is one of the things I think languages should stay un-opinionated about. If I want to use trailing closure syntax for anonymous functions that change outside state, and not use it when it's a pure function, why should the language's formatter complain? Likewise, if I want to use a type annotation because it speeds compile time, why should some formatter/linter complain?
2 Likes
Language style is one of the things I think languages should stay un-opinionated about.
I am 100% agreed. I don’t want it to give a care for style; I want uniformity of format: Where does whitespace go, and how much of it.
1 Like
Even that is going to be a major fight. Some people prefer 4 spaces, some 2 spaces, some tabs. Some like putting a space before a : that declares protocol conformance/subclasses at the declaration site, some don't. Some put a space before : in generic constraints, some don't.
I think the only rules you'll get little fight against are semicolons (probably no fight) and where braces go (probably a small fight).
As long as the fight ultimately terminates and the community can move on, that temporary conflict is fine by me.
I’m interested in what having a uniform code layout enables, not so much in the details of what that layout happens to be.
2 Likes
From my experience with Go, it provides a consistent way for developers to view and understand code that wasn't written by them. In my experience, you don't spend as much time trying to parse the code when you know how certain structures are supposed to look. This was especially helpful when I was new to the language and needed to understand how to make my code more "Go-like". gofmt forced me to adopt the same style as everyone else, which meant that I was able to get more informed help from others.
I contrast my experience in Go with that of my (ultimately unsuccessful) attempts to adopt C++: I couldn't tell what the "proper" way of writing C++ code was; it seemed as if everyone had a different style, and even within projects it was difficult to understand why people did things differently. Determination of code correctness was hindered by this multiple representation.
Again MHO: gofmt is one of the reasons that the language has such a low barrier to adoption (the others being language simplicity – which in my use case led ultimately to my having to abandon it – and tooling, which is something that Swift sorely lacks at the moment, especially cross-platform.)
7 Likes
Everyone has a different style in C++ because there's at least three different ways to do any given thing, and there's been multiple C++ epochs each with their own idiomatic ways to do any particular thing. Very little of it is due to a lack of enforced uniform style.
This isn't even counting things like embedded programming which avoid templates like the plague.
1 Like
One thing I have occasionally thought about is the idea of an all-options formatter that is also fast enough to run transparently.
Such a formatter would allow the editor to, on file load, format the file with the user's preferred format, and then on file save, format the edited file with the save location's preferred format.
Then everyone would only see their preferred format and only their preferred format.
2 Likes
What about git diff?
2 Likes
+1 I too would love to see gofmt for Swift.
2 Likes
I think the best option to make @Dante-Broggi idea work with git, would be to have in the repo a standard format, and then in the IDE being able to provide your own format setting s.t. you can work the way you like.
1 Like
Then people would still have to mentally switch between the standard and the personal style. IMHO the (good) point of gofmt is that having a common formatting standard, even if not perfect, is better than a plethora individual formatting presets honed to perfection.
3 Likes
All of those would be formatted in the standard way. Lemme explain, because I probably didn't do it all that well before:
- The canonical code in git is in the universal format
- The copy of that code in your computer is in the universal format
- Your IDE displays it and "lets" (but not really) you edit the formatting and in fact, it lets you set rules of how to format the code. But all of that is a façade and in reality you're seeing the code in the way you like it better. The way it's stored is always in the universal format.
Therefore, I think? Code reviews, online samples and books would all be formatted in the universal format.
Pair programming is harder to solve. If you have 2 people staring at the same screen, you can't have custom formatting being displayed. If both work together in separate computers, then you certainly could use the same general approach that you would be using for the git repos.
2 Likes
Sorry, I have realized I was not clear enough and edited my post just as you were replying – I would still find the mental switch between the standard and the personal style worse than simply having just a single common format.
1 Like
I do agree with that. To me the mental hassle of having two different styles is too much. I'd probably yield and incorporate the universal standard as my own altogether 
I do think that a universal standard might be unacceptable for some people, though. And I think that's fine. Whatever we end up doing, it should leave space both for "them" (the unyielding) and for "us" (the defaulters)
2 Likes