Coding Principles – Developing the Right Code!




How do we know that we are developing a good code?  One way to find it out is the bug count.

From a developer’s perspective, tremendous effort goes into it.

You would like your code to be:

  • Simple, Readable and Clear –  easy to understand
  • Easy to maintain –  a small change request does not result in a major rewrite
  • Properly modularized, reusable and should follow a robust design

Code Reviews and Mentoring

Nobody is a born developer, so how does this work?  Some of us, who have been lucky to have great co-workers and good mentors in our early programming days, would be able to vouch for the right directions and review comments.

Uncle Bob, in his book ‘The Clean Coders’, emphasizes on the importance of apprenticeship/ mentoring, which should be made mandatory for the fresh talents. So, we know that code review helps in getting a clean and efficient code.

Nowadays, how much of code reviewing is done?  Let alone implementing the comments, after the code has been reviewed.  Also, are you able to make the review a part of a programmer’s daily routine?  Or it occurs and comes up only when a performance issue and code quality is questioned?

The Good Practices

When we work in a team and as a team, how do we ensure a good code and a consistent style across the board? Each developer will have his/ her own style of coding. It would not look good, if one module’s coding style/ standard looked much different from the other.

Based on my experience, while working on one of the projects, we had to develop the solution from the beginning as re-usable modules, and at the same time, there was a legacy code base, as a reference. To have uniformity, we decided to implement couple of generic principles. Of course, we had specific designs for each module, as per the requirement. And some of the areas we considered are:

  • Single Responsibility Principle – The ‘S’ in the SOLID principle says that a class should have one and only one reason to change. This would help us to break things to small and coherent pieces. We need to extend this philosophy when we name the classes, too. Then, we would not have any more generic ‘Helpers’, ‘Managers’, ‘Manipulators’ and rather have specific ‘Validators’, ‘Builders’, ‘Creators’ etc. On a side note, it would create a lot more classes, but the good part is that the code will become easier to comprehend and it will enable faster debugging, too. In fact, if we name our classes, appropriately, anyone who wants to look at the code, would not have to search, too much, to get to the desired logic – the code itself would become handy as documentation for overall flow.
  • Cyclomatic Complexity – It is a quantitative measure of the complexity of the programming instructions. It directly measures the number of linearly independent paths, through a program’s source code. Ideally, it is said to be good, if it is around 10.

For example:

The aforementioned reference values defined, the four approximate ranges for cyclomatic complexity values are:

  1. Methods between 1 and 10 are considered simple and easy to understand
  2. Values between 10 and 20 indicate more complex code, which may still be comprehensible; however testing becomes more difficult due to the greater number of possible branches the code can take
  3. Values of 20 and above are typical of code with a very large number of potential execution paths and can only be fully grasped and tested with great difficulty and effort
  4. Methods going even higher, e.g. > 50, are certainly not maintainable


  • Refactoring – It is the process of restructuring the code and the benefit of which is not easily visible to the outside world.  Putting sincere efforts helps to improve the product code. Both the above said principles would need this. If it is used in tandem, with TDD, it is better. If we have access to the supporting tests, we can refactor, with much confidence. We can say that we have not introduced any bugs by refactoring.

The Conclusion

In reality, it might not be feasible to adhere to a reasonable range always – like a BIG Switch statement, with a higher complexity, which would be simple to understand. Nevertheless, one thing, which is visible, is the area of improvement, when we have a method, with a higher cyclomatic complexity.

There are more areas that need to be explored. Stay tuned to learn more about the coding principles.

As a developer, what are your thoughts on coding good practices?


Divya Sreekanth

Technical Lead & Mobility Expert, RapidValue Solutions




How can we help you?