At Monits we are really passionate about what we do, and that means paying special care and attention not only to how our products work and feel to the user, but specially to the code we write. We strongly believe that you can’t make great software if the source code is always getting in your way. That’s the reason we adopted code review since day 1, over 5 years ago. However, we couldn’t help but notice two interesting facts:

• The more little issues the reviewer needed to raise, the more likely another, more profound issue would slip through
• Most reported issues were recurring ones, specially coding style issues

This was clearly a bad use of our code reviewing time, providing little value,
and not letting reviewers focus on more subtle (and probably higher impact) issues.

It was then, having already adopted Phabricator, that we started adopting static code analysis tools and linters to our workflow. If the code doesn’t comply, the developer is immediately asked to fix it (or provide a really mind blowing excuse) before actually submitting the code for review.

On Java-based projects (both, Android and not), we started using Checkstyle, and later on added PMD (along with CPD), and Findbugs. On Objective-C we use OClint. On HTML5 projects we use ESLint andSass’ built-in linter. Every single language we use has it’s linters and rules.

We loved it. All developers would get immediate feedback on the most common issues, and solve them before the reviewer was even notified of any new changes; allowing it to focus solely on more abstract issues:

• Reusability
• General architecture
• More subtle bugs

The result was life changing, number of issues being raised by reviewers dropped drastically, time spent in code review dropped, and the general quality of code we produced raised.

But we realized this was just the beginning. We saw such a great improvement we decided to keep pushing this way. So we added fb-contrib, an amazing set of extra detectors for Findbugs.

This opened a whole new world of possibilities, and we started to encourage our own reviewers to push the boundaries. Every time you find yourself saying “Why do I keep reporting this same issue over and over?”, that’s a call to go and write a detector for a linter to report it automatically.

We are currently using linters to detect all kind of things:

• Typos
• Bad merges
• Coding style violations
• Bad practices
• Common, easy to miss bugs (think of using == instead of equals)
• Invalid JSON

It was under that very same rationale that we ended up creating our own Findbugs plugin. It all started when, having just included fb-contrib to our toolset, we set out to find something that would allow us to enforce @VisibleForTesting annotation’s behavior. It was then that I came across WorksApplications’s Findbugs plugin, a plugin that did just that, and also included interesting checks such as a few rules for JPA, and enforced the use of JSR-305 annotations. We loved it, but it was only working on Findbugs 2.5, not on Findbugs 3…

We found that Arxes Tolina had forked it, and added support for Findbugs 3… but dropped all Unit tests, and had stopped working on it for a couple months. So we decided to fork it, use find-sec-bugs’s testing tools (after a minor Pull Request), and rewrite all unit tests. In doing so, we found a few cases which weren’t being properly covered, and fixed those.

This plugin soon became the base for a whole new family of detectors. We
have so far added detectors to enforce:

• Effective Java’s item 8: do not override equals if already overridden by a parent class other than Object. Doing so breaks symmetry.
• Effective Java’s item 10: implement toString when the class has any kind of inner state worth showing. Doing so will produce better logs, and greatly help during debug sessions.
• Make sure equals and hashCode use the same fields. Otherwise, you are either breaking hashCode general contract, which states “If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result”, or just creating hash collisions for non-equal objects.

We are constantly pushing ourselves to write better code, and if you are as passionate about coding as we are, we are sure you would also enjoy using these tools. Our Findbugs plugin is open-source, and we would love to get your feedback on it. Issues, feature requests, or whatever!

We are also moving towards open sourcing other tools for code quality, such as our Android Linters, and the integration we built for all these tools for Arcanist. Hopefully we will be able to announce those soon enough.