tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: Removing whitespace from *.xsd and *.dtd files
Date Sun, 23 Oct 2011 22:13:03 GMT
2011/10/24 Mark Thomas <markt@apache.org>:
> 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).
>
> +1
>
>> 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.

1. I hate text editors that change lines that I did not touch.
2. Do you have separate options for trunk and for 3 other branches?

I do not mind if your commit changes whitespace. It does not impede
review. It is your itch, your editor, whatever. There is no technical
merit to discuss when such commit happens.

I do not like this to be enforced on people.


BTW, reviewing properties changes, note the *.properties files in
http://svn.apache.org/viewvc?limit_changes=0&view=revision&revision=1187803

See "jsp.error.usebean.missing.type",
"jsp.error.usebean.prohibited.as.session",
"jsp.error.usebean.not.both", "jsp.error.page.nomapping.language".

They all ended with ":" + space. From quick search though it looks
that most of them, if not all, are unused.

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

All on the next week, or you'll wait after next 6.0.x and 7.0.x?

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message