How to Produce Quality Code? - 5-Step Proven Process.

This article is intended for business owners/CEOs/CTOs/Managers who would like to understand the importance of code quality and Learn my 5 Step proven process to ensure code quality at organization level.

Learning and writing code has never been so much easier than it has been these days. However, there is a difference between writing code and writing quality code. I strongly believe that wiring quality code is an art, Which every developer must learn. Any code produced that does not meet quality standards would intern bring in multiple follow-up issues. Most common problems that most of business owners would have observed.

1. Difficult code maintenance
2. Adding features becomes difficult and expensive
3. Gets harder to add more resources to the team
4. Raise in customer complains

So, what are the properties of bad code?

1) Not readable: Extended Code without comments/grouping, inappropriate naming, often this would result in difficulty understanding logic.

2) Not testable: Inability to write test cases that could be used at later stages to ensure quality.

3) Difficult to extend: due to problems #1 and #2 delays in the delivery of features would be observed as the project progress.

How to Ensure Code Quality then?

Below are the steps that I have identified based on my years of experience in order to ensure code quality.

1) Understand all software quality matrices.

Quality code comprises certain key characteristics and below is the list of these characteristics known as matrices. Let's understand them in brief. all team members must have an understanding of these.

Software Quality Matrices

Robustness: Always write code to handle not only positive scenarios but also to include all negative scenarios as well. Hence, we need to identify as many different combinations of positive and negative scenarios as possible.

Safety and Security: From a code security standpoint, you must apply a static code analysis solution that supports various security standards like OWASP, and CERT. You must identify the static code analysis tool in such a way that it supports security standards in order to ensure that the application will limit vulnerable and insecure states ((buffer overflows, information leakage, script injection, and so on). Sonar lint covers OWASP security standards.

Clarity: Write code that is easy to read and understand. Don't write cryptic code that is hard to follow or easily misunderstood. You don’t want others or yourself to spend a lot of time trying to solve a bug in your code. To achieve this wiring meaningful comments and using constructs like code grouping would be very helpful.

Complexity: Write code that doesn’t have a large number of lines. any function with more than 10-15 lines of code generally must be refactored. Any code based developed this way would be easily maintainable and complexity would be reduced.

Portability: While creating a code base we must create code that could easily be transferred across different machines and devices and becomes independent of device configuration. Dockers could be used for this.

Re-usability: Write code with well-defined interfaces/classes so that it can be reused anytime. This improves productivity in the workflow and reduces labor and testing costs.

2) Identify coding standards

The next step in implementing the Code review process is to Understand and identify coding standards to be followed. Depending upon the type of project there could be different types of standards that an organization has to follow. Here are some of the popular standards.

1) Common Weakness Enumeration(CWE):- The purpose of CWE is to facilitate the effective use of tools that can identify, find and resolve bugs, vulnerabilities and exposures in computer software before the programs are publicly distributed or sold. Some of the key features of CWE include:

• They are Created by US government and industry and managed by Mitre.
• These are Hierarchical trees of weakness
• 800+ rules
• Risk scoring is maintained.

2) Open Web application Security Project(OWASP): These are all open source web-oriented security standards and are mostly language-independent.

• It also has a risk scoring system.
• It is widely accepted and used. FDA uses these standards.

3) SEI/CERT : These are again standards developed with the help of the community. It focuses on prevention. It supports languages like c,c++, Java, Perl, and Android. they have many more targeted in coming years including c#. It also maintains severity.

4) Other standards: There are other standards including PCI-DSS, GDPR which would come into practice depending upon the type of application you are working with.

PCI-DCC – which is the Payment Card Industry Data Security Standard is being followed globally while charging customers' cards through the system.

GDPR – These are standards applicable across Europe and it provides a set of standardized data protection laws.

3) Identify a good static code analysis tool:

Once you understand coding standards and choose one or more we need to identify a static code analysis tool. We have used Sonar Qube and Sonar lint to perform Static code analysis and it supports multiple standards mentioned above.

There are many other static code analysis tools available in the market. below are some of them. we have mostly used SonarQube. here is a link to its test coverage.

4) Implement a static code analysis tool:

Having selected the tool we need to ensure this gets implemented across the organization and all projects will start using it. This will prevent developers from writing bad code and ensure all supported standards.

There would be issues with old projects with legacy development but it could be implemented phase-wise and not in one go.

5) Peer code reviews:

With the help of preemptive code review techniques, we would be able to prevent developers from committing certain mistakes however, there would be areas that would not be identified by static code analyzers. Especially while doing peer reviews we can validate code review matrices mentioned above. Moreover for individual languages, we must derive appropriate standard documents to help peers review the code.

We must ensure any code merge to the master branch should happen only once the reviewer reviews and approves the code this ensures that peer reviews happen continuously. Hence, typically developer must always create pull requests post feature completion and the entire branch would be merged only once code reviews would be done by peer(s).

Finally, all the processes identified must be well documented and defined under organization wikis. One can also align the KPI of team members directly with issue scores being maintained. That would require careful implementation.

I hope this would help to understand this entire subject and help them identify standards for their organization or product. In case you need any further information feel free to reach us at [email protected] or you can visit my website https://envitics.com/contactus and fill in the form real quick and send it back and I would be more than happy to answer.