checkstyle configuration for API

[Machine-Maker]

The checkstyle configuration for the API. The server's will come later and be mostly similar with some key differences (like javadocs and excluding decompiled sources).

Has a file that includes all packages in the API that need to be done. Once removed from that list, all files in it will be subject to checkstyle.

Checkstyle Categories

• Annotations
• Block Checks
• Class Design
• Coding
• Headers
• Imports
• Javadoc Comments
• Metrics
• Misc
• Modifiers
• Naming Conventions
• Regexp
• Size Violations
• Whitespace

[Machine-Maker]

Ok, this is ready to be reviewed. I'm sure there will be things we notice when we start updating all the files it tells us to that we don't want, but we can make those changes as we go along.

This also isn't validated against any formatter yet, so there could be conflicts. We will find those out though as we go.

It also isn't running the custom import order yet, because that will come with the formatter.

[Machine-Maker]

So there's a ton of new logic now in the api's build.gradle. This should probably be moved somewhere, idk if we wanna do the buildSrc thing, or make it part of pw, or what

[kennytv]

I'd leave out final local variables for now to still be able to instantly find "not clean" code, and this one is easy to do automatically in a single commit through IJ later on as well. Otherwise should be good, anything that looks off we can change when we run into it

[NonSwag]

Some things I spotted that might need fixing:

• primitives (fields params and returns) require nullability annotations
• void returns require nullability annotatins
• @NonNull (nullability information in general) infront of the modifiers is allowed if it is on the same line as the method but should only be allowed AFTER the modifiers - example: @NonNull public static X is allowed but should be public static @NonNull X
• deprecated (not marked for removal) class are still checked which seems redundant
• there is no rule about the order of nullability annotation and final in method parameters, should it be @NonNull final or final @NonNull
• package-private and interface methods should be allowed (or even required) to have the nullability annotation not on the same line as the target