Archive for February, 2008

For the sake of this discussion, I’ll divide whitespace into the following categories:

newlines

tabs

end of line whitespace

Newlines

Simply: this is about what character(s) represent the end of a line.

This is a classic! Historically, I would love to know how much time has been wasted on this. Command-line utilities have been built to address this problem. Editors had to accommodate this. Tools had to work around this. Before Mac OS X, we even used to have 3 flavors of end-of-lines ( newline representations and more )!

I could argue that for the sake of future generations, we should agree on one style, preferably line feed. However, tools have gotten better at dealing with this. The problem is tools that aren’t so good at dealing with “foreign” newlines!

Since I cannot impose my will, let’s just agree to be consistent … all the files in your project should be in the same style.

Tabs

Maybe it’s even more complicated… Maybe it means something like “advance the cursor to the next such and such column (multiple of 8).”

Pro-tab people argue that a single tab character is always less characters in the saved file. This serves as a primitive type of compression, to be sure. Nobody can agree on how many spaces a tab character is, whereas everybody agrees how many spaces a space is (1!). The choice seems obvious.

Once again, this problem could be bearable if text editors were consistent, within the same file! Eclipse, for example, will gladly insert spaces, or tabs, depending on what you typed to indent your line at the specific moment. Another “gem” includes opening a tab-indented file and using space-indented lines for new lines (or vice versa).

This is classic “but it works on my machine” reasoning. You know what works on all machines, all the time? … Spaces!

End of Line Whitespace

This one is more of a personal one.

What happens in your text editor when you type a line of code and press a few whitespaces before pressing return?

That’s right … those “precious” whitespaces are kept, invisibly, for you, at the end of the line.

This makes it harder to rework the text later: pressing delete on that line will bring the next line, after the useless whitespace. Incidentally, that depends of what text editor you use.

I’m not going to recommend you constantly monitor your typing and avoid pressing the spacebar at the end of a line… This is more of a tool issue— why do text editors do that? Is there any language/purpose where invisible end of line whitespace is meaningful (as opposed to ignored)?

I use spacehi in Vim and I love to open other people’s files and see how much rework has gone through a file. End of line whitespace is like the secret history of your files!

Recommendations

You can use whichever text editor you want… really!

However, may I respectfully ask you to learn more about the tool you’re using. If a carpenter didn’t know what the claw part of his hammer did ( claw hammer ) and tentatively explained that he didn’t look it up, or never intended on using it, you would be justified in drawing your own conclusions.

In the light of the above text, here are my recommendations:

agree on newline character, within your team

turn off newline conversion in your favorite version control tool

have your text editor substitute all tabs for spaces

In vim, this is done with these settings: (feel free to replace 2 with your favorite number—and, yes, this is a whole other discussion)

set expand tab
set shiftwidth=2
set tabstop=2

have your text editor substitute all tabs for space, in existing files

In vim: (using the above settings)

:retab

if you want to purge end-of-line whitespace the regular expression /s+$/ will help

In vim, I use:

nmap _$ :% s_s+$__g <CR>
vmap _$ : s_s+$__g <CR>

in vim, there’s a plugin called spacehi that will highlight all kinds of whitespace infractions

do whitespace-only commits, this will help greatly in diff-ing revisions if you know all changes from a specific revision to the next are cosmetic only