Whitespace: The Silent Killer


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.



I always highlight bad whitespace in vim.
Search for “RedundantSpaces” here:


it is. Only “leading” whitespace has any meaning in Python.
Anyway, I set up my Vim to treat whitespace at EOL as highlight as error. Nice.


White space has rights too!


As soon as I found an editor that trims whitespace at the end of all lines, had a sane autoindent/autocomplete/codecolor. My sanity thanked me.


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?


I actually prefer having trailing whitespace in my lines, for a specific scenario: to maintain indentation level. Consider this:

…for (int i = 0; i != 10; ++i)


I prefer the above to this:

…for (int i = 0; i != 10; ++i)



“- Run your IDE in whitespace-always-visible mode, or toggle it frequently”

Or use an IDE that always displays trailing whitespace (and tabs, if indentation mode is set to spaces).


Unless the VotingImages and CommentText functions render “” tags, the code has an actual bug.


Oh no, you don’t HTML Encode your comments, just strip the offending strings – anyways that should be “TD”


I agree… OH. MY. GOD! If I ever saw this in my code I would kill the mofo who did it. Luckily I’ve not had that problem… yet.


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.


In Python, EOL whitespace can be relevant!
Try the following piece of code out:

if condition1 and …
…block of statements

Python will complain about that trailing whitespace after the line-continuation character!


And I was just deleting some whitespace from end of my lines today… Damn you, copy and paste! :wink:

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.


I’m surprised! I use Kate for editing and I always thought that every decent editor/IDE had a “remove trailing spaces” option.