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