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
