I used to have my vim set up to trim excess whitespace on write.
I had no idea how many errant diff's that would generate, I had to turn it off.
this post was submitted on 27 Mar 2025
221 points (97.8% liked)
Programmer Humor
22083 readers
278 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Alt
Indiana Jones swapping out an artifact for a fake one meme template with the text "existing code" on the real artifact, "new commit" on the fake one, and "linter" on the pedestal / trap
The right balance on this is to set it up to only trim whitespace on lines that you have edited, and only on-save.
Emacs has ws-butler for that behavior: https://github.com/lewang/ws-butler
That History section is exactly what happened to me
I’ll have to see if there’s a nvim equivalent, or if I can make my own
Yeah, you generally just want the same auto-stuff done as would be enforced in CI anyway.
… all the other stuff you could fix but wind up just ignoring because your team ignores it will just glare at you until you sneak it in somehow
i have prettier auto formatting on save (but also use vim auto format)
I’ve been trying to pair down my extensions, so I’ve been using ale’s fixers to do formatting.
I’m not a huge fan though, I’ll probably go back to vim auto format.
The linter runs automatically on every commit and blocks merges if it fails. Try again
Why linter? I hope your CI has more than just linting turned on
The idea for the meme came to me regarding contributing to a project for the first time. It's not like I will push trash code, but if I accidentally didn't add exactly two newlines between something and it starts complaining...
If there's a linter with such opinionated rules there should also be a pre-commit hook that auto-formats accordingly.
Or on save even. Slow pre commit hooks suckkkk
That's up to each individual developer's own setup. But hooks are a way to ensure uniformity since they apply to all commits.
Why would it be on each dev to setup?
Your repo can, and should, include workspace settings for major editors that provide a uniform experience for anyone onboarded to the platform.
I agree that precommit hooks are good for uniformity. But slow pre commit hooks are frustrating, they are also often turned off. Your CI will always be the last gatekeeper for linting/formatting rules regardless.
Making precommit hooks slower means more devs disable them, which is the opposite of what you want. Save them for simple, read, checks and validations that can run in < 1s for even huge changesets.
That's not a linting problem that's a formatting problem.
That project should have automatic formatting on save setup.
Linters are not necessarily formatters they're solving two different problems and are becoming increasingly separated in their toolset.
for me, it’s rather the tests in the pipelines rather than linting, which happens while I’m writing code