You shouldn't set "trim_trailing_white_space_on_save": true unless you work alone, otherwise you're going to have random whitespace changes polluting your diffs.
Our coding guidelines at Stripe specify that whitespace is to be stripped. It works if everyone does it.
On the occasion where whitespace does pollute the diff, GitHub has a convenient feature where you can append '?w=1' to any diff URL and whitespace changes will be omitted.
The problem with universal whitespace removal isn't the output of the diff, imo, but the spurious conflicts in merges. A change should be minimal to allow easier merging.
Ideally whitespace would be trimmed from lines that have otherwise changed, thus ensuring a gradual (though probably never completing) repair of the code.
The number of pull requests I get where the diffs are completely unreadable because someone has this feature enabled is insane. On certain whitespace dependent languages (I'm looking at you Python) simply supressing the whitespace in the diff is not an option.
What are the arguments for having whitespace removal as a coding standard?
It's dead easy to accidentally add (or remove) trailing whitespace, which you find out at git diff time. Unless you want to have whitespace changes in your commit, you have to manually revert those edits back.
Having the editor just trim those automatically is just delegating the trailing whitespace care to a piece of software with a simple rule: no whitespace allowed.
If the entire team working on a project agrees to this rule, everything's peachy, and it's really easy to convert an existing repo to it - whenever you touch a file, if there are whitespace changes, commit them to a separate commit.
At the end of the day, it's just standard, so doing invasive changes to a project that doesn't follow that standard (as in the pull reqs you descibed) is wrong, but that doesn't mean the rule itself is bad.
As for ST2, it allows easy per-project settings so you can easily enable it globally and disable on a specific project if needed (or vice versa).
we also have a rule that when possible (like you've opened up an old file with whitespace issues), that you should clean it and do a whitespace changes only commit before getting to work. It makes everyone's life easier if they're not looking for the "real diff" in your commit.
It only pollutes your diffs if you're using a crappy diff tool. Whatever tool you use should have full control over showing leading, trailing, consecutive, or all whitespace differences.
No, the main problem is that it screws up merges. Until Git can ignore trailing spaces as part of the merge strategy, it will be a problem when someone removes trailing spaces in one patch and someone else modifies (with real code) those same lines. If you have a largeish number of changes it will be a nightmare.
Nah. Use araxis merge and all your issues go away forever. If other devs want to use shitty tools then that's their fault. If you have a repo and are trying to merge pull requests then you definitely should stop using shitty tools. Even if you don't trim whitespace you should have non-shitty tools for local usage.
