« Back
read.

The value of whitespace changes.

I have a bit of a neatness obsession. I like code to be as clean and tidy as possible (of course based on my subjective view of what makes it that way).

This leads to that I really like things like auto formatting because I strongly believe in that it will every now and then make different choices than humans since it always follows its own rules 100%.

When looking through the diff prior to committing the changes that an auto formatter has made to a file every now and then that will cause me to read functions that I've either never looked at before or just not looked at in a really long time.

Every now and then that leads to that I find a function where there is some really gnarly-looking code that I realise could be simplified a lot.

This is kind of like striking gold for the neatness-obsessed among us. My favourite git commits are the ones with a lot more minuses than plusses, shortening the code and making it more readable has an immense value when you are still supporting it five years down the line and you need to be able to glance at it and see what it does.

More than once this has even lead to me finding code that is actually wrong if given some specific input parameters that it has just never been fed before.

I do not agree with the notion that commits that are just whitespace changes should be avoided because of them "not actually doing anything" and "cluttering up commit history". There is more value to it than you may think.

Heck, goto fail was even a bug that would have been much quicker to spot with correct whitespace formatting.

Don't hate on whitespace commits, they may help you more than you think.