Seems like many of those rules are overlapping with SonarQube checks for instance. I guess this is fine but mentioning it in case of. Since static analyzers can get slow, we might want to avoid doing the same work several times (no idea of the impact of one more rule).
Yes. Actually I’d expect that 100% of checkstyle rules are covered by SonarQube. What is good with the checkstyle rules is that they’re executed fast and locally, without the need for a remote server. Even if we loose access to sonarcloud in the future, we would still have our build verify some checks (we would still loose a lot ofc).
We could decide to disable sonarqube rules that overlap. It’s substantial work to track them down and maintain them over time. Are you volunteering? 
Fine with me.
Done. Big change done in platform. I hope I didn’t break anything (I used Claude Code to help out and reverted 2 places where the reversal of the equals sides made the code fail).
Note that I did a full rebuild of platform to verify (but didn’t run functional tests).
If a tag is not part of the list then it’s ignored from the check.
In view of that I think we could just have:
<module name="AtclauseOrder">
<property name="tagOrder" value="@param, @return, @throws, @exception, @see, @version, @since, @deprecated"/>
</module>
EDIT: if you want to see it in action on xwiki-commons, I’ve made the change at [Misc] Order javadoc tags following the order: @param, @return, @thro… · xwiki/xwiki-commons@dc5f88e · GitHub (but not yet enforced anything at checkstyle level, waiting for an agreement for that part).
ok to add this check: AvoidNoArgumentSuperConstructorCall – checkstyle ?
I see no reason not to though.
+1
+1