There is nothing worse than purchasing a product that occasionally flakes out, freezes up, is slow to respond or has other issues. For developers, there is nothing worse than trying to maintain and update code that is so poor in quality that they are constantly chasing their own tail. For many development teams, software code quality just isn’t where it needs to be. In order to improve code quality, here are several tips developers can follow and integrate into their own processes that will help improve their code quality.
Tip # 1 – Follow Coding Standards
Developers interested in improving code quality should start by examining industry standards. There are many industry standards that developers can leverage to improve the way that they write their code. A few examples include:
- IEC 12207
- IEC 62304
These standards set the framework for developing quality software. Anyone who wants to improve their software quality should review what has already been done and start implementing that industry advice.
Tip #2 – Analyze and Maintain Software Complexity
It has been shown many times that minimizing software complexity also minimizes bug rates. The more complex software is, the greater the changes that there will not only be software bugs, but that performing maintenance on the system will also add bugs. Developers should monitor their function complexity by using Cyclomatic Complexities. To learn more about this complexity measurement, refer to my previous blogs on the topic:
- Using Conditional Complexity to Test Embedded Software
- Limiting Function Complexity shall be a Requirement
Tip #3 – Perform Periodic Code Reviews
Code reviews have been shown to be the most effective method to decrease software bugs. Integrating peer reviews into the development cycle is critical to ensuring that software quality remains high. There are several key factors developers should follow in order to have an effective code review process:
- Limit code reviews to 60
- Don’t review more than 400 LOC’s per review
- Schedule code reviews at a minimum on a weekly basis (more if you generate more than 400 LOC’s per week)
During the code review process, there are several key questions that developers should be asking themselves:
Tip #4 – Requirements must be traceable
If a requirement cannot be tested and verified in some manner, preferably automated, then it is not a true requirement. Before development even begins, the requirements should be broken down into traceable test cases that can later be used to verify that all the requirements have been met. Sure, requirements will change, different design methods will be used, but there needs to be a way to trace software features and functionality back to the requirement that spawned them and prove that they work as expected.
Tip #5 – Compile Error and Warning Free
For a while I thought that producing code with no errors and no warnings was obvious to developers. Very few developers will try to commit code that has errors in it and won’t compile. That one is obvious; However, I run across a lot of teams and developers who will ignore compiler warnings. Sometimes there is just one or two warnings that require a developer to dig deep or are trivial so they are overlooked and just hang around. Other times, I see code with more than 50 warnings! If the compiler doesn’t trust the code and provides a warning, then developers should treat that as a compiler error and resolve the warnings. Warnings are the compilers way of saying that it doesn’t like something. Let’s be honest, a C compiler likes just about anything so if it has a problem with something then as developers we should too. Code quality means no errors and no warnings.
Tip #6 – Statically Analyzed
Static code analyzers are one of the quickest ways to find potential issues with embedded software. A static code analyzer can find issues with syntax, potential glitches and identify non-portable constructs within the code. A static analyzer can even check to see if a coding standard has been adhered to. Integrating a static analyzer into a continuous build process is a great way to improve code quality and minimize software bugs.
Tip #7 – All Code must be Fully Tested
I encounter quite a few small and medium businesses who ship their products without fully testing their software. These companies tend to perform high level spot checks to see if the system behaves the way they expect them to and then send them off into the wild. It probably wouldn’t surprise most readers to learn that these companies then run into issues with their products in the field. As developers, we cannot assume that our code works just because we haven’t seen the system misbehave. Our code needs to be fully tested! Fully tested means that:
- High level test cases have been verified
- Unit testing has been performed
- Integration testing has been performed
- Code coverage testing has been done to verify that every line of code was executed during testing
- System trace analysis to verify that the timing, performance and system behavior was correct and not just appeared correct to the user.
If a line of code was not executed during testing, there is no way to know whether that line of code contains a bug that will one day appear when a user is using the system.
Improving code quality doesn’t have to be a major, expensive undertaking. These tips can be easily implemented and even staged over weeks or months. The end result, will be higher quality software that will provide a better user experience and also decrease development costs.
“High level test cases have been verified” What are these tests?
These in my mind would be your general system input / output tests. Things that the user would be able to do and measure.