On 07/07/2010 17:53, Peter Roßbach wrote: > Then I can check my personal problem with the tab/space replacement, > before checkin code :-) > Currently we have in 144 files a tab instead a space replacement issue.
There is nothing stopping you running FindBugs, Checkstyle or any other tool locally. I use FindBugs on the Tomact 7 code-base all the time. > Ok, I want to fix it. > > Later we can add more checkstyles. Who wants to help, me? > > In the last two years we made a lot of source code cosmetic changes and > these help to get a more readable codebase. Agreed the code-base is more readable. > I think that Marc Guillemot can help us to get more code and test > quality to the project. My impression is that most of these changes are cosmetic rather than code quality issues. I don't think fixing all the current FindBugs, Checkstyle and Eclipse warnings will result in a significant increase in code quality. It would, however, make it easier to spot when errors do creep in. > What does the other developers think? +0 providing we start with a *very* limited set of checks. There should be very clear agreement amongst a significant majority of the committers to add additional checks. I'd like to see a proposed list of checks before this starts being used on any of the Tomcat code bases. I'd suggest a single check for each of Checkstyle and Findbugs to start. I actually think we'd get more value out of the unused code detector. Going through the 7.0.x codebase and removing unused code is still on my todo list. I suspect there is a reasonable amount we can simply delete. Mark > > Regards > Peter > > Am 05.07.2010 um 11:34 schrieb Mark Thomas: > >> On 05/07/2010 09:27, Marc Guillemot wrote: >>> ma...@apache.org wrote: >>>> Author: markt >>>> Date: Fri Jul 2 21:13:25 2010 >>>> New Revision: 960104 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=960104&view=rev >>>> Log: >>>> A few more FindBugs issues >>> > ... >>> >>> why don't you integrate checkstyle (and FindBugs) in the build? >> >> The Tomcat code doesn't follow any standards consistently so the >> number of warnings that would get reported is huge. As far as I am >> aware the actual problems have been fixed. The remaining issues are >> cosmetic. There may be some real issues hiding in there somewhere but >> if there are, they aren't things that users are reporting as problems >> else there would be a bugzilla entry for it. >> >> I don't think (I could be wrong) there is much interest in investing a >> lot of effort in a bug code clean-up. Gradual improvement seems to be >> the preferred approach at the moment. >> >>> It's the only safe way to ensure quality >> >> I don't think it is as black and white as that. These tools have their >> place and I think the Tomcat project has used them appropriately. >> FindBugs, for example, still reports 1000s of issues but the actual >> problems were fixed quite some time ago. The cosmetic issues were not. >> >> There is a valid argument that fixing the cosmetic issues does more >> harm than good by making it harder to do diffs between major versions. >> >>> and to avoid useless style discussions. >> >> I don't recall any useless style discussions. I don't think this is an >> issue we need to solve. >> >> Mark >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
