It seems to me that Robin's campaign is predicated on a prior decision
as to what checkstyle  rules we want to enforce. We can't have it both
ways. if we want to enforce cs compliance for a ruleset, we've got to
make the code comply, and one big tornado has something to recommend
it. If, in fact, we are still in flux in terms of choosing the rules
we want to enforce, then we have a different problem.

On Sun, Feb 14, 2010 at 3:12 PM, Robin Anil <robin.a...@gmail.com> wrote:
> More stats.
> Major violations types in core examples utils
>
> mvn checkstyle:checkstyle>checkstyle.txt
> cat checkstyle.txt|egrep "core|examples|utils" | cut -d":"  -f3-|sed
> 's/[0-9]*://g'|sed "s/'[^']*'//g"|sort |uniq -c|sort -rn
>
>  250  Missing a Javadoc comment.
>  92   hides a field.
>  90  Name  must match pattern .
>  54  Line is longer than 120 characters.
>  45   is not followed by whitespace.
>  40  Constructor definition in wrong order.
>  36  Variable access definition in wrong order.
>  36  Variable  explicitly initialized to  (default value for its type).
>  30   is not preceded with whitespace.
>  21  Wrong order for  import.
>  21  Variable  must be private and have accessor methods.
>  18  More than 7 parameters.
>  17  Type Javadoc comment is missing an @param <T> tag.
>  17  The method  should be named .
>  17  The method  must be declared with no parameters.
>  11  Static variable definition in wrong order.
>

Reply via email to