I recently discovered that an incorrect closing quote in a string will break it.

Cute.

Things where "incorrect" can break it: everything. Things where "trailing whitespace" can break it: almost nothing, and for good reason. On the extremely rare occasions when I find something where trailing whitespace matters, it is usually just admitted as a bug. I can't even think of any cases of that right now except for heredocs.

I can't even think of anything where

one space
[download]

makes a difference compared to

two  spaces
[download]

And you can actually see that difference.

And, yes, even ignoring all of that, making it easy to get the delimiter wrong for a heredoc is much worse than getting the delimiter wrong for a string.

sub flutz {
    # ...
    my $blob= <<END;
        ...
END 
    # ...
}

sub flortz {
    # ...
    my $blob= <<END;
        ...
END
}

if( int rand 2 ) {
    flortz();
}
[download]

compiles completely fine. Of course, it often produces:

Undefined subroutine &main::flortz called at - line 16.
[download]

when you run it since I wrote the example to make it relatively trivial to notice that the intervening code has just "gone away".

But I can't even make this example demonstrate why because the important part is invisible. (Update: Even highlighting the above code doesn't show the trailing whitespace, at least for my environment.)

Construct an example where getting the closing quote wrong compiles without error. It won't be nearly as easy as this.

And while you are trying, you'll probably have a chance to notice that Perl often goes out of its way to help you see your mistake via something like:

blah blah blah at - line 13, near "blah"
  (Might be a runaway multi-line '' string starting on line 4)
[download]

This is done because experienced programmers figured out that when getting the closing delimiter wrong it can be hugely frustrating to find the source of the problem.

I'm not sure whether you were dismissive just to be funny or if you actually were trying to be dismissive. But I responded because I didn't want other readers to dismiss the point based on your clever dismissal, preventing them from thinking much about the point and realizing how crazy significant trailing whitespace is.

You'll probably deride the notion, but I've long since had my editor configured to 'strip trailing whitespace on save' when editing source files for every programming language I use.

I was seriously frustrated by the effects of the presence of a space after the \ on a continuation line. Once bitten, twice shy.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Our code review tool shows trailing whitespace in red. I should make sure our git is configured to complain about commits that include new/changed lines containing trailing whitespace. My editor is configured to make trailing whitespace visible. But, no, I don't have it automatically strip such. But I do often strip all trailing whitespace.

One reason to not unconditionally strip whitespace has to do with merge conflicts, so I will usually commit whitespace changes in a separate commit from any other changes. Once bitten by having to spend hours on a merge conflict due to extensive whitespace changes interfering with automated merge resolution, twice shy. :)

But if you don't have to worry about that case, I have a hard time coming up with a compelling argument against automated removal of trailing whitespace.

I've long advocated not using chomp but instead doing s/\s+$// because trailing whitespace should never matter (it also helps avoid problems with unexpected \r characters, which also shouldn't matter).

When composing my prior node, I recalled being worried that the C preprocessor might not properly handle an at-line-end \ if it is followed by a space. I did a quick test and the first cpp I ran across didn't have that bug. But I'm not surprised if other (especially earlier) versions did.

- tye