We recently compiled and analyzed a selection of some of the most widely used software metrics (you can download our report here). As part of the work, we asked our users what shortcuts they had taken and wish they hadn’t.
Disclosure: Codacy, the automated code reviews platform, has previously sponsored Hacker Noon. For Hacker Noon readers, they’re offering 15% off using this code: HACKERNOON.
“I think one of the most valuable rules is avoid duplication. “Once and only once” is the Extreme Programming phrase.”
- Martin Fowler
This is easily the number one rule. If you want your code to be rock solid and live forever, then duplicated code is the best way to torpedo your objectives. That’s because if you find a bug in one copy, you’ll have to fix it in all the other copies. That’s assuming that you can find them in the first place, or that you are even aware of them. This multiplies the time — and therefore costs — to test and debug.
“Complexity kills. It sucks the life out of developers, it makes products dif cult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration.”
- Ray Ozzie
A measure of code complexity is cyclomatic complexity, which is the number of logical branches that the code can go through. In practice, it’s often approximated by the number of expressions such as IF, WHILE, FOR, FOREACH.
The thinking is that the more control statements you have within a method, more complex it is, the harder to read and understand the code, and therefore the higher the risk of something backfiring.
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
- C.A.R. Hoare
The story goes like this: Bob X edits package A, which depends on package B. John Y edits package B, which turns out to depend on package A.
Hilarity ensued. Not.
Code design is the way the different packages, modules, classes and methods are linked to each other. Having an idea of how a specific area of the code is connected to other areas of the code reduces the odds of turning your work into a game of Jenga.
No silver bullet here. A healthy mix of code reviews, testing, and a pinch of software metrics (whether it’s afferent/efferent coupling, distance from the main sequence, etc.) might be helpful.
“Program testing can be used to show the presence of bugs, but never to show their absence.”
- Edsger Dijkstra
Test test, and test your code. Unit tests. Functional tests. Regression tests. And keep an eye on code coverage.
Code coverage is only as good as the tests that underpin it but it’s a great way to foster a culture of continuous testing. It happens to have other benefits too: it provides some level of confidence in the code, and it helps identify areas of the code that need further testing early in the development lifecycle.
Let’s start with the bleeding obvious: good code is code that does its job well but is also easy maintain, extend and debug. And for code to be easy to maintain, extend or debug, it must be easy to read and understand.
Having style guides goes a long way towards enabling this, which is why companies like Google have adopted with gusto. For starters, by limiting choice, it removes unnecessary sources of distraction. Developers can focus on functionality as opposed to, say, naming conventions. It also makes sharing code easier for them. Last but not least, it provides a certain degree of predictability: if all your functions use camelCase, then anyone who reads your code knows that `sendMessage` is a function, not a parameter or a variable.
The style guide advice is somewhat controversial, and there are valid arguments on both sides of the debate. One side sees the benefits extolled in the above paragraph. The other side highlights the fact that style guides are like straight jackets, with no impact in the final product. Both arguments have their merits, so in the following section we list two articles with the two opposing views.
“Everything is complicated if no one explains it to you.”
- Fredrik Backman
If writing new code is the fun bit, code commenting is the tedious chore that most of us would rather do without. In an ideal world, the code is so self-explanatory that no comments are required. However, there are times when you need to clarify what the purpose of that code is. It makes code maintenance easier and facilitates collaboration on projects. No matter how you look at it however, good code also means good comments. As a result, the time needed to comment your code should count towards the total development time.
If you read this, you probably know that code reviews serve several purposes:
But let’s sprinkle the above with some hard, cold, data points, taken from McConnell’s code complete book:
“… software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive: