7 Coding Shortcuts That Don’t Work

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.

1. Duplicated code

“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.

Things to consider

• Aim for zero duplicated code in production environment. You probably won’t get there 100%, but it’s a worthwhile goal to have.
• Factorize, factorize, and factorize your code.
• Test, test, and test your code.

Food for thoughts

• Refactoring. Martin Fowler. Link.
• “Coming Full Circle On Code Duplication”. Link.
• When Code Duplication Is Acceptable. (Fagner Brack, 2016) Link.

2. Not measuring — or managing — code complexity

“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.

Things to consider

1. Keep an eye on cyclomatic complexity. Like any software metric, it is far from perfect, but at the very least it will flag potential hotspots and may even trigger some healthy re-thinking.
2. Remember: a method or a class is never too small.
3. As much as possible, follow the single responsibility principle.

Food for thoughts

• Path Testing: Independent Paths. Jeff Nyman. Link.
• A complexity measure. Thomas J. McCabe. IEEE Transactions on Software Engineering, Vol. SE-2, No 4, December 1976. Link.

3. Forgetting code design

“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.

Things to consider

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.

Food for thoughts

• Single responsibility principle. Wikipedia. Link.
• A validation of object-oriented design metrics as quality indicators. Basili et al. 1995. Link.
• Software package metrics Wikipedia article. Link.
• Law of Demeter Wikipedia article. Link.
• Design Principles and Design Patterns. Object Mentor. Robert C. Martin (2000). Link.
• OO Design Quality Metrics. An Analysis of Dependencies. Robert C. Martin (1994). Link.

4. No tests. No code coverage

“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.

Things to consider

• Aim for code coverage of 80% approx. but remember that code coverage is only as good as the quality of the tests that drive it.
• High code coverage is no guarantee of quality. But low code coverage should make you pause and think.
• Developers should aim to spend 10% approx of their time on unit tests until they reach the targeted code coverage threshold.

Food for thoughts

• Testing, fun? Really? Link.
• Code coverage. Wikipedia. Link.
• Testing and code coverage, Paul Johnson. Link.

5. No style guide

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.

Things to consider

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.

Food for thoughts

• Coding standards horror story. Link.
• Why I Have Given Up on Coding Standards. Richard Rodger. Link.

6. Too many comments, or no comments at all

“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.

Things to consider

• Too much comment is counter-productive, it makes the code difficult to read and maintain.
• Rather than setting rigid guidelines on the number of lines of instructions per comment, follow common sense rules such as good code style on naming variables and methods, self-explanatory code, and the occasional comment explaining why this bit of code does what it does.

Food for thoughts

• The Fine Art of Commenting. Bernhard Spuida, 2002. Link.
• Code as documentation. Martin Fowler. 2005. Link.

7. No code reviews or code reviews that are too long

If you read this, you probably know that code reviews serve several purposes:

• They are the single best practice to ensure code quality.
• They facilitate team collaboration
• They help apply code standards
• They help identify bugs early in the development process.
• They help with developer onboarding and learning.

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:

• In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
• In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
• The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
• IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
• A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
• Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.”

Things to consider

• Apply code reviews systematically, for example with every commit. Also, consider adding a review column on your scrum board and make sure everyone sticks to it, including the team leader.
• Different people bring different perspectives, so make sure it’s not always the same people who review the code.
• Break the code reviews into small daily sessions and keep them short 4–5 hours per week is about right.

Food for thoughts

• Seven Truths About Peer Reviews (Karl E. Wiegers). Link.
• Code complete. (Steve McConnell). Link.
• Code Reviews: Just Do It. Link. Coding Horror. Link.

Thanks for reading! If you enjoyed it, hit that heart button below :)

Also, we’ve also compiled a review of the most widely used software metrics in an ebook, free for all to download:

Click to get the ebook