Checkstyle is often perceived as a tool to solely enforce code formatting standards. And it really does a great job with that – without Checkstyle, a project with five developers would have ten different coding styles. Or thousands, considering what some of the “Knights of the Copy and Paste” are sometimes capable doing to innocent sourcecode.

However, Checkstyle does a lot more than just enforce code formatting rules. Checkstyle really is a tool to enforce coding standards, which includes much more than mere code formatting and layouting. For example, Checkstyle can also detect poor class and method designs. This makes it a very helpful tool to define rules and coding best practices, and enforce them in the project.

I find three aspects of Checkstyle particularly useful for security static code analysis:

• Enforce of a common coding style, which includes format / layout.
  This helps tremendously during code reviews: The time of a security expert doing code reviews is extremely valuable. They charge high rates, and they cannot do the job for long periods of time before getting tired and begin to miss things. If the project (or even an organization) uses a single style consistently, then this means less ramp up time for the security reviewer, and less time to review the code.
• Prevents developers from violating best coding practices.
  There are many discussions around which “best practices” really are “best practices”. However, eventually someone in a project team must make the call, and define what code constructions should and should not be used. Bloch gives some good examples in his books (e.g. Effective Java 2^nd Edition – still a great resource even though it is a little dated: https://cebulko.com/Programming-Resources/Effective%20Java%20-%202nd%20Edition.pdf), and Checkstyle can help to enforce a lot of them. Some really useful checks are the various complexity checks. If these fail, then this is almost always an indication of poor class design.
• Forces creation of proper code and API documentation.
  Let’s face it: most developers do not like writing documentation. The minimum amount of documentation that a developer should include in a commit are the API docs, e.g. in form of Javadocs. Without proper API documentation, security code reviews are extremely difficult. Re-use of such code is also difficult, which makes useful API documentation a good investment in the first place.

Checkstyle is highly configurable through “checkers”, with each “checker” performing a specific analysis task. The checkers themselves often have various options to fine-tune how the checker exactly works, and what variants / specifics of a rule it should enforce.

An overview of all currently supported checkers is available here. A good starting point when creating a Checkstyle configuration for a new project are the Sun and Google reference configurations. They provide very useful defaults, and it is often much easier to start e.g. from the Sun configuration and tweak it, rather than create a configuration from scratch.