this post was submitted on 17 Jul 2024
72 points (95.0% liked)
Programming
17351 readers
342 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 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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 -w
only 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.