In my opinion, different people have different formatting preferences and forcing someone to use the "wrong" one will lead to slower reading speed and the risk of overlooking errors.
That's why I believe we should treat it like font or color choices. The IDE should display source code in the viewer's preferred style, so that each person sees what they expect. And then the actual source code formatting becomes irrelevant.
Go already goes a good step into this direction by making a language AST tree part of their core libraries. And opening Go source code in JetBrain's GoLand will show you additional annotations, spacing, etc. based on the parsed source code tree (and not based on the source code's text).
Everyone can just set up a pre-commit hook to automatically format the code back into the official style, then everyone is free to put the codebase back into their preferred style.
Otherwise, if developers reformatted code to their preferred style regularly, it would create massive diffs.
In this explanation about Go:
https://golangdocs.com/golang-ast-package
the text following "and we get a nice structure" is what the source code management tools would be working on. It's an abstract representation of the source code's meaning, but not tied to how things are formatted or indented.
The method I described does exactly that. Most modern formatting tools parse code into an AST then rewrite it based formatting rules. So as long as you format both files to the same rules before diffing, only AST changes will show up.
I genuinely feel that focusing a lot on the detriment of someone else's or an established code style is a sign of a lack of team work.
[1] Incidentally the only people I know with carpel tunnel are folks who are entrenched in command line text editors. Maybe there’s some benefit to moving your arms around? Similarly maybe there’s benefit in reading code in a different format, you might actually read it slower and hence comprehend it better.
Not if everybody using the language is strongly forced (as with Go), since then those with "different formatting preferences" will eventually (and soon) just get used to the enforced style.
I would not be surprised if a lisp formatter following the same philosophy as the dart formatter would be similarly complex, since the complexity comes from optimizing line length, not parsing.
https://jyp.github.io/pdf/Prettiest.pdf
It's based on introducing choice between vertical and horizontal stacking. It avoids combinatorial explosion by pruning away strictly suboptimal choices. With just a few extra rules for Lisp forms, the results are quite good.
I don't handle comments though, since I only need it for pretty printing values so far.
You got that right -- check out this epic GitHub thread on optional semi-colons [1], and the author's own comment on the subject in an HN thread [2]
I realized there was a tradeoff I never considered — the amount of time it would cost me to manually format only 10% better than the black formatter is not something I am willing to invest.
And this is me talking about ideal situations where I calmy try to write beautiful code, when you consider that often you are not in the mood to spend a ton of time on formatting, because it distracts you from focusing onto the actual data flow, logic and so on a formatter as good as this is just beautiful.
This is not something I would've said before I tried the thing btw.
That feels like Prettier sometimes. I think it leaves some objects on multiple lines or one line depending on how you leave them. But I’m not too sure.
I've been thinking lately of a formatter that would resolve this tension. It would be a local, individual formatter, complementary to the global, opinionated, "Prettier" formatter.
When the source code was committed to remote for review, the opinionated formatter would do its thing, making sure the code was formatted properly according to whatever the team agreed. But locally, the code would remain however the developer liked it.
i think maybe your only hope is to somehow “version the AST”, and let formatting be a style sheet or something. But i’m 1. talking out my butt and 2. sure i’m missing something.
One problem though is all of the non-code elements, aka comments and how they intentionally align up with the code (mixed with spaces and tabs), so the ideal format is the one the original programmer wrote it in, and the second programmer using a different stylesheet can't edit comments and have them end up pretty for the first programmer. (The solution, obviously, is to not comment any code >_< )
E.g.
(+ 1 2) ; Add two numbers.
(comment (+ 1 2) "Add two numbers")
Another would be
(+ ; Adding
1 ; one
2 ; and two.
)
((comment + "add")
(comment 1 "one")
(comment 2 "two"))
But isn't this the nearest argument why we should start publishing negative results papers?
The most important thing that I have ever learned was a announcement made by Google about how their industry consortium seeking to trade print magazine advertising inventory, failed with reference to the nature of this failure. No matter how lacking in detail this notice was, no matter that I was sent down a seven years solitary and very lonely path of mercifully ultimate discovery, on the heels of my startups exit collapse due to my cofounder tragically dying but we'd have been sunk by the problems indirectly revealed in that Advertising Age news item. However painful, and I'm talking about therapy for years after I emerged from reclusion, and real health issues giving up running and my diet turning to junk energy hits...I have learned more from being told "no can do Z because of y" and I seriously think that we /seriously have to start already getting over the reasons why we don't talk about our failures/. I mean holy smoke wouldn't we ever run out of good conversation ever again if we could have a good old banter and brew over our cockups? I'm thinking that this is how women are so much more successful in reproduction if they actually want to. What could we do if we tried?
That's a good expression of the idea. If merge conflicts happen, we're doing it all wrong. Version control shouldn't even really be aware of this.
The language is fairly complex syntactically and that definitely adds some cost to formatting.
But I think much of the complexity comes from two things:
1. A lot of idiomatic Dart uses function literals in a block-like way, as in:
test(() {
expect(1 + 2, 3);
});
someFunction(
() {
expect(1 + 2, 3);
});
It's not as good as a human (mainly because it doesn't have semantic context) but it had to be pretty close or people wouldn't have tried it.
Now that it's well established, I think it would probably be possible to simplify how it formats while still making users happy. Possibly happier because the results would be a little easier to predict.
> Code isn't just a recipe for a computer to do something, it's a language for explaining to other programmers what that thing is and what's important to the structure of accomplishing it.
An automated formatter will never be as good as carefully crafted artisanal formatting. In particular, automated formatters don't know what stuff means. A good human might choose to line break a function call like so:
setColor(red: 123, green: 54, blue: 26,
alpha: 45);
But the value proposition of automated formatting is not just "how nice is the resulting code to read". You have to look at the total value proposition of completely yielding formatting to a tool versus allowing human control over it. When it's completely automated:
1. You can run it on generated code that contains absolutely no whitespace and still get nice output.
2. Humans can do large-scale refactorings, format, and get output that is consistent with the existing state of the codebase without having to understand any local style preferences.
3. Humans never have to spend time deciding how to format. Further, they don't even have to spend time deciding if they should format.
4. When reading a random codebase, it is likely to be formatted in a style you are used to even if you have zero communication with that team. This is particularly important in open source.
5. The code looks familiar to you wherever you encounter it: IDEs, plain text editors, code review tools, blog posts, StackOverflow answers. As opposed to letting everyone pick their own style and relying on users to apply their preferred style locally, it's just always in a familiar style.
6. Like any automation, the tool doesn't make mistakes. Even very careful humans hand-formatting make more mistakes than they realize. (I know because I've looked at their code). Those mistakes can be distracting for readers.
7. It gets people out of the mindset of being nitpicky about style. It encourages them to stay focused on the structure and naming of their code, which is what really matters.
8. It eliminates style arguments in code reviews. Those take time and, worse, cause disharmony, for next to no benefit.
I think it's very worth excepting some small loss of overall formatting quality to get those in return.
I think I'd still prefer to see a formatter attempt to preserve any formatting which is already 'good enough' to pass as an output threshold. Code isn't just a recipe for a computer to do something, it's a language for explaining to other programmers what that thing is and what's important to the structure of accomplishing it. The choice of where to place a break can matter for cognition and can be almost as important as the printed characters for organizing thoughts.