tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ro├čbach ...@objektpark.de>
Subject Re: svn commit: r960104 - /tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
Date Thu, 08 Jul 2010 06:05:54 GMT
I totally argreed with Marc Guillemot.

It is time to more invest to the cosmetic things at the tomcat code  
basis.

Peter


Am 08.07.2010 um 07:37 schrieb Marc Guillemot:

> Hi Mark,
>
> Mark Thomas wrote:
>> ...
>> 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.
>
> what about sharing the config and including it into the build?
>
>>> 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.
>
> The checks make sense if they are accepted by the majority of the  
> committers as they should be integral part of the build. This is the  
> reason why I've only proposed one check in patch 49268.
>
> According to the negative comments on commits, everybody should  
> agree on following checks
> FileTabCharacter -> currently 146 failures
> JavadocType (versionFormat) -> currently 539 failures
>
> Following simple steps could be:
> RedundantImport -> 11 failures
> UnusedImports -> 53 failures
> ModifierOrder -> 211 failures
> RedundantModifier -> 1377 failures (seems that nobody knows the  
> default visibility rule of a public interface)
> LeftCurly -> 498 failures
> EqualsHashCode -> 5 failures
> FinalParameters -> 12763 failures
> FinalLocalVariable -> 8201 failures (not so much Java developers  
> really know how the power of the final keyword)
>
> Additionally it seems that you pay attention at some warnings  
> emitted by your IDE. It would be interesting to express these rules  
> as checkstyle (or whatever) rule that can be checked automatically.  
> Can you list the Eclipse style warnings you try to fix?
>
> I agree that coherent code style is only cosmetic in a first time as  
> it doesn't change the resulting byte code. Nevertheless it makes  
> easier to concentrate on the important things: the code content,  
> without being distracted by the form. Therefore it helps to find  
> real problems and make easier to compare files, apply patches, ...
>
> Cheers,
> Marc.
> -- 
> Blog: http://mguillem.wordpress.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


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


Mime
View raw message