Re: trivial trailing whitespace issue

[Mark Mielke <mark at mark dot mielke dot cc>]

On 11/26/2009 08:18 AM, Michael Matz wrote:
> How, for goodness sake, can pure trailing whitespace changes, which by
> necessity you can't even _see_ in an editor (except if you activate modes
> that explicitely show them e.g. in different color) clean up code?  Have
> you looked at the patch or fallout from it?  If not, why do you speak in
> favor of it?

I'm an outside observer with professional ties to SCM.

This issue is similar in scope to TAB vs SPACE for indenting. Whether 
you can see it or not is not indicative of whether it has downstream 
effects or not.

Generally, whitespace on the end of lines is bad, and cleanup eventually 
becomes necessary. It is "bad" because people will accidentally change 
lines without realizing them, and these changed lines show up in patches 
and annotations. This goes both ways - a lot of people browse code in vi,
and accidentally add space to the end of lines they don't even intend to 
change. Or, maybe their editor automatically strips whitespace at end of 
line when they re-indent. Who knows? Same happens with TAB changed to 
SPACE or back and forth. Once these start to accumulate - they create 
downstream consequences that multiply. You can't see it, but every 
program that the file passes through *does* see them.

Is cleanup in bulk the right approach? You either clean up over time or 
you do it in bulk. In my own projects, some of the designers I worked 
with had horrible habits in this regard. Every second line would have 
whitespace on the end. The longer it is left, the worse the effect.

As software architect for our project, I notified the team I was doing a 
cleanup, and did it in bulk. Due to the notification, everything went 
smooth.

It sounds like the idea should have been proposed and accepted. 
Everybody would have been ready for it, and nobody would be upset. Oh well.

It's been entertaining. gcc@gcc.gnu.org is normally pretty dull to 
read... :-)

Cheers,
mark

--
Mark Mielke<mark@mielke.cc>