Add checkstyle [SPR-16968] #21506
Phil Webb commented
First off, a massive apology for the size of the PR. It turned out to be a lot more involved that I first thought. Other than the number of files touched, I don't think there's too many controversial parts to the PR. Perhaps the one that might cause the the biggest concern is the change in imports. I've added rules to enforce the import order based on the rules in the WIKI but I've also enforced that
The other one that might be a bit controversial is single argument lambdas. In Spring Boot we opted to always use the parentheses around the argument so that single argument and multi-argument lambdas look the same.
Let me know if you want me to refine any of the rules or rework the commits in any way.
Juergen Hoeller commented
Phil, there is plenty of good polish in that PR but it also adapts a few widespread things that we intentionally did differently: e.g. no copyright headers on package-info, no "this." prefix on logger access, no type+"this." prefix in inner classes for access to outer state... and allowing star imports in test classes.
Generally speaking, I'm not sure whether enforcing production checkstyle guidelines on test sources is necessary or even desirable. At the very least, we could have more relaxed guidelines for test sources. For a start, enumerating the assertion method imports for every single test class feels odd to me... but I'm also generally much more relaxed about the code style used for test methods or inner classes used by them, with many production rules not needing to apply there.
As for single-argument lambdas, I visually object to the enforced parentheses there. Frankly, I'd rather wrap the expression itself in additional parentheses than such a plain parameter name part. We knew you chose differently in Boot but I'm afraid I'm not up for changing our style here in this respect.
The equals/hashCode stuff is unfortunately a common false signal by style-checking tools. All of those classes were valid since the superclass
With respect to consistent code blocks and consistent ternary expression style, there were a few glitches... but also a few cases where we intentionally used one-line if variants, e.g. in
All in all, from where I stand at the moment, the PR itself is way too much to merge. Let me rather go through the commits individually and hand-pick key changes while ignoring a whole range of others... and see where we end up with. In particular, I'm going to focus on production source fine-tuning, not touching test sources unless there is something totally bogus there. Once I've done an initial pass through this, let's see which checkstyle rules we'll eventually set up.
Last but not least, thanks for your efforts there! This is pointing out a lot of stuff worth reviewing, even in areas where we might not enforce hard rules eventually.
Phil Webb commented
Thanks for the fast review, I know there's a way too much in one PR so I was expecting to need a few rounds. I might be able to do something with the commits I have locally which are a lot more fine grained.
I figured some of those were intentional, but I wasn't 100% sure. For Spring Boot I have a lot of IDE templates and auto-cleanup enabled so I've tended to take a blanket rule over exceptions. For example, if I create a new class file I get the copyright header, but Eclipse doesn't give me a way to skip it only for
I intentionally started this PR with the same approach to see what you thought about it. I think with checkstyle we can refine the rules to enforce what we want. I'll have a look to see if we can refine some of those checks to also enforce the exceptions. For me, one of the biggest benefits to checkstyle is helping to know what the rules are. I had no idea that
It's easy to add a blanket exclude for
No problem, I wasn't 100% sold on it myself at first in Boot (but I do really like the consistency now). I can refine the checkstyle rule in the other direction and enforce that all single parameter lambdas must not have parentheses.
I agree, It's a little pointless. On the other hand, it found at least one that was genuine I think. Do you think the empty
I could either drop the rule, or add an exception for the few cases where it looks better shortened. I'm personally in favor of hard rules here, just so nothing is open to interpretation. I think I use more brain cycles working out why a bit of code is formatted differently than just dealing with more whitespace.
If we drop test checks then those blocks won't be enforced. On the other hand, if it's test code perhaps if doesn't really matter if they take up a bit more space? The ternary things is a bit strict as well. Stephane pointed out that you polish a lot of them to use
I'm happy to have another pass here as well if it helps. Splitting out the PR into test, production and unwinding a few of the rules discussed above shouldn't take me too long. Probably the most labor intensive part was the javadoc changes so I'd be super happy if those could go in?
Sorry it ballooned into such a monster. It really ended up being quite extreme all things considered!
Sam Brannen commented
Phil Webb commented
Juergen Hoeller I've forced pushed a second round so the PR should be a bit easier to digest now. I know you wanted the javadoc one as a different PR but I've left it in this one for now (otherwise I can't get checkstyle to pass).
Here are the updates: