On 23/10/2011 23:13, Konstantin Kolinko wrote: > 2011/10/24 Mark Thomas <ma...@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.
Fair enough. We all have the things that drive us slowly nuts. > 2. Do you have separate options for trunk and for 3 other branches? Yes. I have no intention of back-porting the white-space changes to 7.0.x or earlier. > 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. We can limit the checkstyle check if you feel strongly about this. > 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. More stuff to delete then :). I'll take a look unless you beat me to it. >> 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? I wish :). I suspect that this will be a long process. I intend to do it gradually as I have the time. My gut feeling is it will happen over months. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
