“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
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
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 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…
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.