Whitespace: The Silent Killer

“Now to imagine, to our dismay, that there’s all this stupid, useless whitespace at the ends of our lines.”

There are no(*) whitespace-at-the-end-of-the-line issues in Perl.

(*) Except within literal texts, patterns (e.g. regular expressions) and formats.

Yes I’m very smug about it :wink:

More seriously one thing I hate about end-of-line whitespace is this issue:

for my $variable (some_array) {

many

lines

of

code

}

Frequently in code from other people there will be a whitespace after the opening brace, which makes it impossible to click your mouse at the end of the line and jump to the closing brace - instead I find my cursor stuck in the end of some annoying useless whitespace.

Thankfully I can remove all end-of-line whitespace in my editor with a single command, so it’s not such a big issue as you make it out to be. I just have to remember to do it :slight_smile:

Barry: why not let your IDE insert those spaces for you? It’s what it does best, after all. It will also create the spaces for you on a new line.

Stack Overflow: How to automatically remove trailing whitespace in Visual Studio 2008?
http://stackoverflow.com/questions/82971/

Git treats trailing whitespace as a bad thing.

Then, when you try to commit code that was written on Windows (CR/LF) it thinks you’ve got trailing whitespace.

Then you have to add -n on the end of the commit command, particularly if you’re trying to commit someone else’s Ruby plugin.

I think Macs add CR/LF or not and don’t care.

The problem here is not the whitespace, it is the fact that there are two different languages weaved together with different rules for whitespace (one of which is C# code and one of which is HTML). In the HTML the whitespace means one thing, in the code it means something else (it is insignificant). The programmer has to deal with two different syntaxes in the same file! If the data and code were expressed in the same syntax, this wouldn’t be an issue.

If you were using a web framework where the HTML is expressed as code, this issue wouldn’t arise. Consider a table in the seaside web framework or a framework for one of the lisp dialects.

html table:
[html tableRow:
[html tableData: ‘cell1’.
html tableData: ‘cell2’.
html tableData: ‘cell3’].
html tableRow:
[html tableData: ‘cellA’.
html tableData: ‘cellB’.
html tableData: ‘cellC’]]

(:table :border 0 :cellpadding 4
(loop for i below 25 by 5
do (htm
(:tr :align “right”
(loop for j from i below (+ i 5)
do (htm
(:td :bgcolor (if (oddp j)
“pink”
“green”)
(fmt “~@R” (1+ j)))))))))

In these examples you couldn’t have the whitespace issue since it is all expressed as code in a single language (and would have to respect the syntax and whitespace rules for one language). This is much more elegant that the template method of mixing HTML & code.

A long time ago I wrote an e-lisp function for Emacs to remove trailing whitespace and I call this when I save. Unfortunately sometimes I have to avoid calling this function when editing a file for checking back into version control.

(defun buffer-whitespace-remove-trailing ()
“Function for removing all trailing whitespace in document”
(interactive)
(save-excursion
(beginning-of-buffer)
(while (re-search-forward “[ ]+$” nil t)
(replace-match “” nil nil)
)
)
)

It doesn’t handle tabs, and that’s deliberate, because in some languages (like Make) tabs are significant.

I, too, would like to know the issue with the above code; all I see is that a line containing several spaces will be interspersed between blocks. Is this so? Did I miss something?

I’m not alone in my freakness.

One doesn’t need to highlight whitespaces. It’s enough to highlight end-of-line.

More than 30 comments, and nobody’s mentioned markdown?

I’m sorry, but if your code is affected by trailing whitespaces, that’s a problem with the language. We have processors today that are millions of times faster than the big iron of old where processing every byte during a compile took time.

It is a complete waste of a programmer’s time chasing down something as ridiculous as that. Terribly inefficient use of resources.

It’s funny. Lately at work i have been working a lot with Joomla and VirtueMark, they have all this extra white-space. We are talking whole lines with nothing but 20 spaces on them and it’s not to keep things indented. drives me nuts…

Or pick it up when you diff it before commiting to source control. Picks up other invisible changes like tabs and BOMs also.

Or pick it up when you diff it before commiting to source control. Picks up other invisible changes like tabs and BOMs also.

This is where it is nice to have an IDE that automatically removes EOL whitespace.

You need a vacation. Period. Space.

Wow, I was seriously beginning to think that I was the only one who obsessed about this.

Could someone explain to me why those extra spaces kill the JavaScript?

I mean, they wouldn’t cause a problem in C, and that’s got one of the worst syntaxes ever foisted on programmers - apparently.

Could someone explain to me why those extra spaces kill the JavaScript?

I mean, they wouldn’t cause a problem in C, and that’s got one of the worst syntaxes ever foisted on programmers - apparently.

And you really need to fix this double posting bug.

Actually, that are two issues. First, trailing whitespace is just unclean. Aggressive removal causes spurious merge conflicts. (Nothing compared to windows svn users committing dos mode files, though.) Unfortunately eclipse does either sprinkle trailing whitespaces (ugly) or removes all of them, even those that were there previously, causing conflicts. git has the decency to only complain new trailing whitespace.

Whitespace in HTML/XML is a completeley different issue. The extra spaces in the example don’t matter functionally (AFAICS), but make the resulting HTML look bad. On the other side, HTML/XML indenting is formally a bad idea anyway, exactly because whitespace is significant in XML. Only only wonder once why an XML parser returns lots of document data when the document is if the say-nothing (no apparent marked-up text) X’M’L type.