Hacker News Reader

Comment by fxtentacle | Hacker News Reader

I feel like enforcing a specific text style is the wrong approach.

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).

View on HN

Having a strictly (formatter) enforced style is actually how you allow people the freedom to use their preferred style.

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.

I feel like I might have explained that badly. In my suggestion, the source code would be diffed as a machine-readable AST tree. That means all source code reformatting actions which do not change the meaning of the source code also do not appear in the diff.

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.

I agree it would (maybe) be better if things had been designed this way from the beginning, but as it is it would be totally incompatible with all existing source code management tools, which is a nonstarter. Even if you can switch to a new editor or IDE, you still have to worry about the GitHub web UI and your error reporting tooling and who even knows what else.

> That means all source code reformatting actions which do not change the meaning of the source code also do not appear in the diff.

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.

On paper I like this idea. But I can't shake the feeling that every non-text based format I have ever encountered sucks.

And this is how git works with the different newline styles. It can convert them to a single enforced style on commit and converted back when you pull changes.

I've never had that work correctly. Mostly it just gets in the way when the line endings actually matter (because my javascript has to load in IE7).

From experience I can tell that one can get used to other people's styles and just work with that oneself. Unifying among an enforced style and sticking to it really reduces the amount of unnecessary discussions.

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.

The AST usually isn't enough, you want a CST (or what a few sources call "full" syntax tree, preserving white space, comments, etc). I think .NET has the best implementation of this out there, unsurprisingly they have incredible tooling support.

For anyone interested in CST tooling outside of the .NET ecosystem, tree-sitter[1] is general purpose, quite fast, supports a wide range of grammars, and has bindings in quite a lot of environments (including WASM, so likely can be used anywhere with some effort).

1: https://tree-sitter.github.io/tree-sitter/

Tree sitter is absurdly complicated to use in a real project, a hand written parser might be slower but it's way easier to implement and build.

I haven’t used it in a real project yet, but I’ve tried it out for a few project ideas, and haven’t found it complicated to use. I’m not necessarily saying it isn’t ever complicated, but I was able to knock out a couple proofs of concept in a few hours. My only complaint so far is that the sexpr representation lacks some details, but I have no problem with working around that.

This seems like the arguments devs stuck on vim and eMacs keep making. “Ohhh I’m tired of moving my fingers from one key to another!!” [1] It’s just code, if you’re in a good team each PR is just a small diff, it’s hard to believe that’s somehow too complicated for an ostensibly good engineer.

[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.

I am one of those folks entrenched in command line editors, and I avoid carpel tunnel by using a real keyboard (in my case, a real IBM model M) and not the absolute crap that passes for keyboards on laptops (or those keybords in the $1 discount bin).

Good for you but I stick to a standard apple chicklet keyboard and thin mouse and feel the most productive. The mix of moving your arm but always having it rested flat helps in my experience.

>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.

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.

Reply on news.ycombinator.com