tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Removing whitespace from *.xsd and *.dtd files
Date Sun, 23 Oct 2011 21:08:49 GMT
On 23/10/2011 10:39, Konstantin Kolinko wrote:

> I am -1 on applying trailing whitespaces check on *.java files.
> It has no practical value. It does not improve readability. I do not
> see what it can be useful for. It is just useless nagging.

Trailing white-space is pointless and it bugs me. Maybe that is just me,
but I'd like to get rid of it.

My original plan was to just configure my IDE to remove trailing
white-space when I saved a file but that led to the occasional noisy
commit where the white-space changes hid the real change if I forgot to
do a white-space only commit first. That was starting to get tricky
keeping track of which files I had 'fixed' and which ones I hadn't.

Given the above, removing all of the trailing white-space in one go
(well, several goes as a single commit was just way too big) seemed like
the sensible way forward.

In terms of benefit, it shaved ~1% of the compressed source. Nothing to
write home about I agree but 1% pointless fat removed it still 1%
pointless fat removed.

Having gone to the trouble to remove all the trailing white-space, I'd
like to keep it that way and enabling the check-style check is the
simplest way to do that. It does mean folks working on trunk need to
configure their IDEs to remove trailing white-space on save for that
project but that doesn't seem like such a big deal.

> There are file types where check for trailing whitespace is useful,
> e.g. *.properties files, (because whitespaces are not trimmed from the
> values that are read from the file and might be visible).


> But for *.java files I do not see any benefits.

In absolute terms, the benefit is minimal (~1% smaller source files) but
the bigger benefit for me is that it doesn't bug me any more.

On a related topic, unused code is next up on my list of things to clean
up. My plan is 1 commit to trunk to mark it deprecated. Back-port that
commit to 7.0.x and then remove it from trunk. I'll probably do this
package by package but I'll see how it goes.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message