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
