luc.maison...@free.fr wrote: > ----- "Phil Steitz" <phil.ste...@gmail.com> a écrit : > >> I would like to add checks for >> >> 1) System.out.println() statements in the code >> 2) Trailing spaces >> 3) Files that do not end with newline characters >> >> Currently 1) generates no errors, but 2) and 3) generate quite a few. >> >> I will fix the errors in current sources and add the checks if others >> >> are OK with this. >> >> The reason that I want to add 2) and 3) is to make it easier / less >> noisy when creating or applying patches when using editors that strip >> >> trailing spaces and/or expect source files to end with newlines. >> >> Any objections? > > This is great. I would also like to tighten the checks in the same spirit as > the ones done in Nabla. > > I think the following ones would be nice additions and would probably not be > very difficult to fix: > > <module name="AvoidStarImport"/> > <module name="ConstantName"/> > <module name="DeclarationOrder"/> > <module name="FallThrough"/> > <module name="GenericIllegalRegexp"> > <property name="format" value="@author"/> > <property name="message" value="developers names should be in pom > file"/> > </module> > <module name="HiddenField"> > <property name="ignoreConstructorParameter" value="true"/> > <property name="ignoreSetter" value="true"/> > </module> > <module name="HideUtilityClassConstructor"/> > <module name="IllegalCatch"/> > <module name="IllegalImport"/> > <module name="MissingSwitchDefault"/> > <module name="RedundantModifier"/> > <module name="StringLiteralEquality"/> > <module name="ModifierOrder"/> > <module name="MultipleStringLiterals"/> > <module name="MultipleVariableDeclarations"/> > <module name="TodoComment"/> > <module name="UnnecessaryParentheses"/> > <module name="UnusedImports"/> > > I'm also a big fan of the following ones, but they may lead to large diffs to > fix. Of course, if we agree to add any of these checks, I will handle fixing > the code myself: > > <module name="FinalLocalVariable"/> > <module name="FinalParameters"/> > > > The last set is probably less important and will also create really huge > diffs so it is probably not worth the trouble. I can still do it, using the > --ignore-space-change and some shell/sed magic to do extra checking and be > sure only white space is changed before committing such new rules: > > <module name="Indentation"> > <property name="basicOffset" value="4"/> > <property name="caseIndent" value="0"/> > </module> > <module name="NoWhitespaceAfter"/> > <module name="NoWhitespaceBefore"/> > <module name="WhitespaceAround"> > <property name="tokens" > value="ASSIGN, BAND, BAND_ASSIGN, BOR, BOR_ASSIGN, BSR, > BSR_ASSIGN, > BXOR, BXOR_ASSIGN, COLON, DIV, DIV_ASSIGN, > EQUAL, GE, GT, > LAND, LCURLY, LE, LITERAL_CATCH, LITERAL_DO, > LITERAL_ELSE, > LITERAL_FINALLY, LITERAL_FOR, LITERAL_IF, > LITERAL_RETURN, > LITERAL_SYNCHRONIZED, LITERAL_TRY, > LITERAL_WHILE, LOR, LT, > MINUS, MINUS_ASSIGN, MOD, MOD_ASSIGN, NOT_EQUAL, > PLUS, > PLUS_ASSIGN, QUESTION, RCURLY, SL, SLIST, > SL_ASSIGN, SR, > SR_ASSIGN, STAR, STAR_ASSIGN"/> > </module> > > Luc
I am +1 on all of the above. As long as we separate the commits so there is no substantive code change embedded, the large diffs should not be an issue. I have a bunch of local mods related to MATH-287, which I will hopefully get committed today. Then I will move on the first batch above (unless someone screams between now and then). Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
