javaThere are many tools that control the quality of Java code, including Checkstyle, PMD, FindBugs, Cobertura, etc. All of them are usually used to analyze quality and build some fancy reports. Very often, those reports are published by continuous integration servers, like Jenkins.
Qulice takes things one step further. It aggregates a few quality checkers, configures them to a maximum strict mode, and breaks your build if any of them fail.
Seriously. There are over 130 checks in Checkstyle, over 400 rules in PMD, and over 400 bugs in FindBugs. All of them should say: “Yes, we like your code.” Otherwise, your build shouldn’t pass.
What do you think? Would it be convenient for you—to have your code rejected every time it breaks just one of 900 checks? Would it be productive for the team—to force developers to focus so much on code quality?
First Reaction
If you join one of our teams as a Java developer, you will develop your code in branches and, then, Rultor will merge your changes into master. Before actually merging, though, Rultor will run an automated build script to make sure that your branch doesn’t break it.
As a static analysis tool, Qulice is just one of the steps in the automated build script. It is actually a Maven plugin and we automate Java builds with Maven 3x. Thus, if your changes break any of Qulice’s rules, your entire branch gets rejected.
Your first reaction—I’ve seen it hundreds of times—will be negative. You may actually become frustrated enough to leave the project immediately. You may say something like this (I’m quoting real life stories):
“These quality rules entirely ruin my creativity!”
“Instead of wasting time on these misplaced commas and braces, we’d be better off developing new features!”
“I’ve done many successful projects in my life, never heard about this ridiculous quality checking…”
This first reaction is only logical. I’ve seen many people say things like this, in both open source and commercial projects. Not only in Java, but also in PHP (with phpcs and phpmd) and Ruby (with rubocop and simplecov).
How do I answer? Read on.
On Second Thought
My experience tells me that the sooner someone can get used to the strict quality control of Qulice, the faster he/she can learn and grow; the better programmer he/she is; and the further he/she can go with us and our projects.
Having this experience in mind, I recommend that all new project members be patient and try to get used to this new approach to quality. In a few weeks, those who stick with it start to understand why this approach is good for the project and for them, as Java engineers.
Why is it good? Read on.
What Do Projects Get From Qulice?
Let’s take one simple rule as an example. Here is a piece of Java code that Qulice would complain about (due to the DesignForExtension rule from Checkstyle):
public class Employee {
public String name() {
return "Jeff";
}
}
What is wrong with this code? Method name() is not final and can be overridden by a class that extends Employee. Design-wise this is wrong, since a child class is allowed to break a super class, overriding its method.
What is the right design? This one:
public class Employee {
public final String name() {
return "Jeff";
}
}
Now, the method is final and can’t be overridden by child classes. It is a much safer design (according to Checkstyle, and I agree).
So, let’s say we make this rule mandatory for all classes in the project. What does the project gain from this? It can promise its members (programmers) a higher quality of work, compared to other projects that don’t have this restriction, mostly because of:
Predictability of Design—I don’t have to scroll through the entire class to make sure it doesn’t have methods that can be accidentally overridden. I know for sure that this can’t happen in this project. In other words, I know what to expect.
Less Hidden Tricks—Higher predictability of design leads to better visibility of mistakes and tricks. Standardization of source code makes it uniform. This means that it’s easier to read and spot problems.
Industry Standards—The decision to use this design is made by Checkstyle, not by a project architect. For me, as a project developer, this means that I’m following industry standards. That makes the project (and its leaders) more respectable.
Learning—I’ll bet that most of you who read this post didn’t know about the design rule explained above. Just by reading this article, you learned something new. Imagine how much you could learn after making your code compliant to all 900 rules of Qulice (Checkstyle + PMD + FindBugs).
The point about learning brings us to the last, and the most important, thought to discuss.
What Do I Get from Qulice?
As a programmer, I hope you already realize what you get from working in a project that raises its quality bar as high as Qulice asks. Yes, you’ll learn a lot of new things about writing quality Java code.
On top of that though, I would actually say that you are getting free lessons with every new line of code you write. And the teacher is a software, written by hundreds of Java developers, for the last ten years. Qulice just integrates those software tools together. Truthfully, it is the developers who are the real authors of quality checks and rules.
So, what do I tell those who complain about quality rules being too strict? I say this: “Do you want to learn and improve, or do you just want to get paid and get away with it?”
ps. You can use my settings.jar for IntelliJ, they are rather strict and will help you clean your code even before Qulice starts to complain.
