On 08/02/2012 20:51, Vincent Hennebert wrote:
Hi Chris,

Hi Vincent,
<snip/>
Can you provide a breakdown of the new warnings identified by Glenn by rule
type? I do object to introducing so many new warnings and I'm not comfortable
with using automated tools to correct the files, without understanding exactly
which warnings will be fixed in an automated way.
Here is the list of rule violations that I get when running the new
Checkstyle file on the latest trunk with Checkstyle 5.5:
       1 FinalClassCheck
       1 GenericWhitespaceCheck
       1 NoWhitespaceBeforeCheck
       2 DefaultComesLastCheck
       4 RedundantModifierCheck
       4 RightCurlyCheck
       5 OneStatementPerLineCheck
       8 RedundantImportCheck
       8 RegexpSinglelineCheck
      33 ConstantNameCheck
      37 MultipleVariableDeclarationsCheck
      47 UnusedImportsCheck
      71 EmptyBlockCheck
     113 NewlineAtEndOfFileCheck
     128 NoWhitespaceAfterCheck
     182 LineLengthCheck
     249 ImportOrderCheck
     321 ParenPadCheck
     392 MethodParamPadCheck
     806 ExplicitInitializationCheck
    2231 WhitespaceAfterCheck

Thanks for preparing the breakdown. I've reviewed them and agree with your analysis. Most of the ones that occur frequently are easily fixed by the Eclipse Formatter, with the exceptions you've raised below. Although the formatter may break long lines at unfavourable places? I propose that we remove this rule as Glenn suggests and it will avoid lines being broken in awkward places too.

Thanks,

Chris


A description of the rules sorted by alphabetic order can be found here:
http://checkstyle.sourceforge.net/availablechecks.html

ImportOrderCheck and UnusedImportsCheck are easily fixed by bulk-running
Eclipse’s import organizer.

ConstantNameCheck and MultipleVariableDeclarationsCheck will have to be
fixed by hand but the number remains reasonable.

ExplicitInitializationCheck can’t be automatically fixed by Eclipse
AFAICT. We may have to drop this rule as fixing it manually would be too
much work.

For the rest, either they are automatically fixed by the code formatter,
or the number of occurrences is small enough to be manageable by hand.


Vincent

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to