Aside of looking bad, trailing whitespace (or inconsistent tab/space policies or line endings for that matter) can really screw merges in revision control systems and can turn your “blame” (or how that function is named in your version control system) session into a world of hurt because seemingly identical lines actually aren’t.
Since I moved over to git, I got really picky about this as the git workflow makes you merge much more often as creating branches is so easy. Also, git is really picky about whitespace too and warns you very loudly if you screw up.
Back in the days of RCS, we developed code in Windows and Unix environments with their differing conventions of newlines. When Windows guys saved a file, they replaced every Unix newline with Windows newline, and vice versa. It was horrible mess: you could never tell which line actually were modified.
Then me migrated to CVS, and due the problems, we also deprecated use of Windows newlines. There was even a trigger that prevented committing files that contained them. dos2unix was to be used every time before commit.
Everything was fine for a few months, CVS making our lives easier, until one day the commit kept failing even though dos2unix was used conscientously.
It appeared that during the realier years, the newline struggle somehow corrupted the files, and it was unrecoverable. Upon every commit, CVS became confused as to what newlines to use and sometimes it reverted them to the Windows newlines. I don’t know why, and I don’t bother to know why, but this actually happened.
So, why on earth, newlines do matter in plain textfiles when it comes to revision control? You could still store them in whatever format they are, and get them outthe same, but every comparison related operation could ignore the differences sooooooo easily.
As Sam alluded to, be glad you’re not hacking make files. Putting in four spaces where you meant to put in a tab can ruin your day.
Python is easier to deal with. Just set your editor to always insert spaces and you’re fine. What you see is what you get. But make files depend on the distinction between tabs and spaces. Hard to imagine that decades later programmers still put up with this.
For Visual Studio, the magic shortcut is Ctrl-K,D (Format document). Note that this will not remove extra whitespace at the end of comments, so you might also wish to do the regular expression replace (find :b+$ and replace with empty string).
Hello, I am not one of you but still I enjoy reading this blog. I am looking at your example code and wondering what the big deal is, since I am not a programmer. May I ask where is the bug in the whitespace? Does it make the browser crash? Or does the program behave differently? I have read the comments and I understand that this whitespace can trigger false positives when comparing two versions of a same file using a source control tool. But what is the effect when running the code?
We have one developer here (only one) who doesn’t run with Visual Studio’s “Auto-Format on Save” feature enabled. You can always tell when he was the last person to check in a file. Well, you can tell when you’re diffing your own changes at least.
@NotAProgrammer: Besides space issues (the output will be a few bytes longer), there’s nothing wrong. Except that IT IS HORRIBLE. It makes you feel like the person who did it should die an horrible fiery death of a thousand burning suns. Twice. A day.
Trailing whitespace and tabs (bird tracks in Visual Studio) should definitely be removed from the end of lines. Sometimes I think my colleagues are trying to encode Morse code with a combination of tabs and spaces.
And I was just deleting some whitespace from end of my lines today… Damn you, copy and paste!
Incidentally, has anyone done studies into the levels of OCD within software development? I have a mild form (need to check the house is locked a few times before leaving), and some code foibles.
