News for hackers. Stuff that matters.
Re:The hardest program I've ever written (2015) by ramraj07 on Saturday March 05, 2022 @07:34AM (#30566974)
It might be true but as OP says in the article, the moment you have potential multiple ways to show the same piece of code, you’re going to surface engineers with each opinion on the code review. Getting an opinionated formatter is the best way to bring engineers back to do what they really need to be doing in code review, which is review the code not its formatting. I’ll never go back to python without black and Isort!
Re:The hardest program I've ever written (2015) by fxtentacle on Saturday March 05, 2022 @08:14AM (#30567261)
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).

Re:The hardest program I've ever written (2015) by davemp on Saturday March 05, 2022 @10:06AM (#30568163)
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.

Re:The hardest program I've ever written (2015) by fxtentacle on Saturday March 05, 2022 @10:39AM (#30568416)
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.

Re:The hardest program I've ever written (2015) by ameliaquining on Saturday March 05, 2022 @10:57AM (#30568564)
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.
Re:The hardest program I've ever written (2015) by davemp on Sunday March 06, 2022 @12:33AM (#30575287)
> 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.

Re:The hardest program I've ever written (2015) by rowanG077 on Saturday March 05, 2022 @04:10PM (#30571901)
On paper I like this idea. But I can't shake the feeling that every non-text based format I have ever encountered sucks.
Re:The hardest program I've ever written (2015) by hiccuphippo on Saturday March 05, 2022 @11:18AM (#30568749)
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.
Re:The hardest program I've ever written (2015) by delusional on Saturday March 05, 2022 @11:37AM (#30568943)
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).
Re:The hardest program I've ever written (2015) by awild on Saturday March 05, 2022 @11:51AM (#30569125)
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.

Re:The hardest program I've ever written (2015) by duped on Saturday March 05, 2022 @11:41AM (#30568996)
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.
Re:The hardest program I've ever written (2015) by eyelidlessness on Saturday March 05, 2022 @04:19PM (#30572004)
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/

Re:The hardest program I've ever written (2015) by duped on Saturday March 05, 2022 @05:17PM (#30572504)
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.
Re:The hardest program I've ever written (2015) by eyelidlessness on Saturday March 05, 2022 @07:44PM (#30573705)
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.
Re:The hardest program I've ever written (2015) by ramraj07 on Saturday March 05, 2022 @01:54PM (#30570647)
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.

Re:The hardest program I've ever written (2015) by spc476 on Saturday March 05, 2022 @07:00PM (#30573338)
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).
Re:The hardest program I've ever written (2015) by ramraj07 on Saturday March 05, 2022 @09:47PM (#30574550)
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.
Re:The hardest program I've ever written (2015) by coldtea on Saturday March 05, 2022 @12:20PM (#30569496)
>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.

Re:The hardest program I've ever written (2015) by chrisweekly on Saturday March 05, 2022 @11:51AM (#30569124)
Agreed! I use Prettier (driven by ESLint) in all my web projects (including enterprise clients', where I've helped introduce / improve / standardize tooling). IME it's a mistake not to use it.