Thanks for your sharing about the ideas. Better rules should make a better environment.
Speaking of findbugs, @adoroszlai raised a ticket about "Applying spotbugs check to test code", which is to improve code quality even for test codes. Lately I was working on it and finished the checking of all test codes in Ozone. There should be improvements about the commits since there are lots of changes, really appreciate if everyone could help to review the commits if got time. Thanks very much. Jira ticket: https://issues.apache.org/jira/browse/HDDS-2195 <https://issues.apache.org/jira/browse/HDDS-2195> PR: https://github.com/apache/ozone/pull/1806 <https://github.com/apache/ozone/pull/1806> > On 26 Jan 2021, at 6:09 PM, Lamber Ken <lamber...@apache.org> wrote: > > Thank you all for sharing your idea, especially Marton. > > On 2021/01/26 09:23:25, "Elek, Marton" <e...@apache.org> wrote: >> I am also +1, but couldn't resist to add some more thoughts ;-) >> >> I think all the checkstyle/findbugs rules have three goals >> >> 1. correctness (usually findbugs rules not checkstyle rules) >> >> 2. readability >> >> 3. merge-ability >> >> >> In this case it's slightly more readable to use the standard convention, >> but improves the merge-ability a lot. >> >> Similar to to import order (which should be forced, IMHO) wrong order >> can cause unnecessary conflicts. (I see a lot of trivial conflicts due >> to different import orders). >> >> So I think it's a good step forward. >> >> But one additional comment. I like this quote: >> >> >> "If code style can't be enforced by linter, don't argue about it" >> >> (source: https://blog.rstankov.com/collaborative-single-player-mode/) >> >> >> For me it's not just the linter, but the code formatter. It would be >> great to provide default, project specific formatter specification for >> different IDEs (but first of all, for IntelliJ). >> >> For this specific case it's not strictly required (as I am pretty sure >> that it's already followed by the default styleset) but in general it >> can help to improve the checkstyle and code formatter all together, >> making it possible to adopt more codestyle rules with minimal burden. >> >> (Again, it's not strictly related to the proposal, just a god occasion >> to discuss related questions ;-) ) >> >> Marton >> >> >> On 1/26/21 2:19 AM, Lamber Ken wrote: >>> Hi Community, >>> >>> According to "Java Language Specification"[1], found some problems that X >>> modifier out of >>> order with the JLS suggestions in the codebase. So, I think we can add >>> ModifierOrder to checkstyle rules to enforce modifier order[2]. >>> >>> I don't know if other people have opinions on it. >>> >>> [1]: https://docs.oracle.com/javase/specs/jls/se11/html/jls-8.html >>> >>> [2]: https://github.com/apache/ozone/pull/1839 >>> >>> >>> >>> Thanks, >>> Lamber-Ken >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org >>> For additional commands, e-mail: dev-h...@ozone.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org >> For additional commands, e-mail: dev-h...@ozone.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > For additional commands, e-mail: dev-h...@ozone.apache.org >
