73
How far should a programming language aware diff go?
(semanticdiff.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 Jul 2024
73 points (95.1% liked)
Programming
17314 readers
226 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
4 is sheer madness. 1 is common sense. 2 is just the cooler version of 1.
I've always found hardcoded style to be an obnoxious and counterproductive paradigm. It's the text editor's job to handle line wrapping, and there's no reason a coding editor shouldn't be able to format code intelligently. I hate hard line breaks that do not have meaning. Not everybody is using the same size windows! It's 2024! We have the technology!
The example for 2 isn't good. Seemingly superfluous commas, brackets, and escaped newlines can be useful and even important for clean maintenance.
The solution to the whitespace gripe is strictly enforced formatting standards with a git hook running a manually invokable script.
Yeah but sometimes you do get meaningless changes that aren't just whitespace even with auto formatters. For example if you change the indentation on some code and that causes it to wrap an expression.
How is that not whitespace?
git diff -wonly ignores whitespace within a line (e.g. changing indentation). It doesn't ignore adding or removing new lines.But even if it did, wrapping a function call or a long string can introduce extra commas or quotes.
Throwing a linter into the pipeline just hardcodes the formatting at that point in the pipeline. That doesn't really solve the issue, which is that style is not a one-size-fits-all concept, and displaying text appropriately is really the job of a text editor. To quote PEP 8, "default wrapping in most tools disrupts the visual structure of the code". In other words, "most tools" suck at displaying code, because they are not language-aware. That's the real problem. Hardcoding style is a workaround, not a solution.
That said, I wouldn't consider intelligent editors to be a replacement for formatting standards, either. Ideally my text editor would display my Python code the way I like it, and then save to disk in accordance to PEP 8.