The notion of code quality gets thrown around quite a bit in the software engineering circles, yet when asked to define what quality code is, most people start enumerating rules and criteria. No one can really give you a good, concise definition.
I would argue that one of the most important qualities of good code stems from the SRP — changes external to a unit should never break functionality from that unit. This includes inherited functionality and other things. To give a very specific example, methods like
hashCode() should keep working in a subclass, so long as the subclass doesn’t add any new fields.
The other big cornerstone of quality code, in my opinion, is consistency.
Due to the way our brain has evolved, we’re really good at predicting things and really bad at handling information that contradicts those predictions. Coincidentally, this is also why you befriend people who agree with you, and why most people are really bad at debating differing opinions in a calm, reasonable manner.
Always remember that you are absolutely unique. Just like everyone else.
Different people write code somewhat differently. Only slightly, but enough to mess with your expectations, and this causes you stress. This is the prime reason behind why whether you place your opening brace on a new line or at the end of the previous one would cause a nuclear war if devs were given access to such means.
This problem is where style guides come in and why every company worth its salt has one — because consistent is better than my way. Your brain gets used to consistent things, even if the things are ones you initially dislike.
and now you do what they told ya…
Enforcing all of these little things is a different matter though. Because
Managing senior programmers is like herding cats.
you cannot simply tell them to stick to the style guide.
This is where automated tooling like SonarQube comes in. It’s a tool that runs all your static analysis and style checks automatically, once you submit code to it. It allows you to manage your rules in one, central place, instead of having to maintain the same rulesets in each project’s repository. It’s well integrated, has a good plugin for IntelliJ, runs [almost] all the checks that Checkstyle, FindBugs and PMD do, detects code duplication, etc.
It also lets you create a dashboard, plays nice with Jenkins and has an API. This in turn means you’re able to actually enforce its usage and rulings, thus preventing code style feuds and making sure you don’t die of a thousand cuts.
What about you? Do you have experience with SonarQube and integrating it into your pipeline? Let us know!
If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.