There are a bunch of ways to take care of the code quality, still I think the best option is to minimize the effort and let the machine do a significant part of the work.
Of course, the machine will not be able to validate our meticulously crafted class design, the correctness of the business logic, or just following the common sense, yet all other aspects can handle surprisingly well. I guess most of you use some or maybe all these tools in your projects. If you are that person, that is fantastic – you can stop reading and consume something more beneficial 😉 If not, that is also great because setting up these tools is extremely simple and you will get all benefits right now.

Checkstyle – to (not) forget about the code conventions 🙂

As it states in the GitHub repo of the project, Checkstyle is the tool for checking Java source code for adherence to a Code Standard or set of validation rules (best practices).
To be more precise, it is actually for checking all those conventions and rules you want to have in your project (because you may not like all of them:)). Checkstyle is configurable, there are lots of different rules
and you can disable these you do not want to adhere to. IMHO a couple of existing rules are pretty strict and can be annoying for developers. Keep in mind it can provoke vigorous discussions if you introduce Checkstyle to the brown-field project 🙂 The tool will fail the build (or show a warning) if rules are broken. Still, for a well-thought configuration, it is exactly what we need. Additionally, Checkstyle can scan our code for unwanted pieces of code that matches the regular expression. IntelliJ code formatter can also respect the Checkstyle configuration which will make them in sync.

Benefits of the Checkstyle:

• easy and quick configuration
• can point out issues immediately during the build process
• easy customization of the rules
• rules i.e. from Sun and Google (Available here)
• the configuration file can be stored in a single place and accessed by multiple projects by URL. Below example of the Gradle plugin and Sun checks:

  checkstyle { config project.resources.text.fromUri("https://raw.githubusercontent.com/checkstyle/checkstyle/master/src/main/resources/sun_checks.xml") }

What to avoid:

• using too strict rules – can be annoying and make the team hate Checkstyle instead of loving that
• discrepancies between the IDE formatter and the Checkstyle configuration
• fixing all issues in a legacy project can take a while (although we can define rules as warnings and fix issues later)

ArchUnit

This fantastic tool can validate the overall architectural approach to our code and our own conventions in the project. Extremely beneficial to keep things like custom naming conventions or relations between packages in order. Like Checkstyle, it will fail the build, so expect very fast feedback! You can read more in my previous post: Guard your architecture by ArchUnit

Benefits of ArchUnit:

• easy and quick configuration
• can point out issues immediately during the build process
• great, understandable API that allows writing tests quickly
• suitable to guard the architecture and code conventions even after writing a few tests

Modernizer

Modernizer plugin helps to find places in code that use legacy Java APIs which are obsolete and shall be replaced by newer ones. Sometimes we can be surprised that we already use a legacy API (we are getting older :)) but this plugin especially shines in legacy projects we want to clean a bit. As with other above plugins, it fails the build so the feedback is immediate. Here you can find the API recognized by the Modernizer Gradle plugin as obsolete.

Benefits of Modernizer:

• easy and quick configuration – once again!
• fast feedback in the build process

SpotBugs (a new FindBugs)

Another tool that can point out issues in code. Just attach the plugin to the build file and voila – SpotBugs will do a static analysis of your code and generate a report with all possible flaws. SpotBugs is a fork of well-known but abandoned FindBugs. It can be a great companion to other tools like SonarQube. Especially since the static analysis can be done fast and locally.

Benefits of SpotBugs:

• Have I mentioned already an easy and quick configuration of these tools?:)
• Generates readable reports of all found issues
• Configurable, can also fail a build if it finds issues

Drawbacks of Spotbugs:

• obviously, this is rather a simple tool that cannot replace other more powerful analyzers

Configuration:

For Gradle, including a plugin and just this simple configuration is enough to generate XML and HTML reports:

spotbugs {
    ignoreFailures = true
}

spotbugsMain {
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

spotbugsTest {
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

PMD

Like SpotBugs, PMD can also find flaws in our code. It is highly configurable as we can write our own rulesets. It has all benefits of the previous tools so I am not going to repeat them over and over 🙂 Definitely worth trying.

JaCoCo thresholds

To automatically guard the project quality, it is also cool to use the JaCoCo thresholds that will complain if the project fails to meet their criteria, i.e. the code coverage decreases below the minimum threshold. In Gradle, it requires just a few additional lines. Below is the example for the line coverage:

jacocoTestCoverageVerification {
    violationRules {
        rule {
            limit {
                counter = "LINE"
                value = "COVEREDRATIO"
                minimum = 0.6 // will fail if the coverage is lower than 60%
            }
        }
    }
}


Summary

There are much more powerful tools like SonarQube that will do a similar job to the above tools and present results in a pretty UI. Nevertheless, attaching tools like ArchUnit, Checkstyle or SpotBugs will
take more than 10 minutes in most projects. Their customization is also super easy. The real benefit is fast feedback, and the possibility to run them completely offline. That kind of automation can significantly help us in delivering a better code that requires less effort in code reviews and overall maintenance. They will also help in delivering a cleaner code, regardless of personal changes or a more tight schedule. Also, how many devs check Sonar every day? 🙂 I think spending an hour to set up and configure them will pay off immediately.

Bonus

Recently I have joined a few passionate folks who started the YouTube channel – “KodowanieBezCenzury”. In my first video, I recorded the content of this post. This time, in Polish. If you prefer videos over reading, enjoy!