this post was submitted on 17 Jul 2024
72 points (95.0% liked)

Programming

17433 readers
280 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
[–] SpaceNoodle@lemmy.world 7 points 4 months ago (2 children)

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.

[–] FizzyOrange@programming.dev 1 points 4 months ago (1 children)

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.

[–] SpaceNoodle@lemmy.world 1 points 4 months ago (1 children)
[–] FizzyOrange@programming.dev 1 points 4 months ago

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.

[–] AnAmericanPotato@programming.dev 1 points 4 months ago* (last edited 4 months ago)

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.