David Maidman – Control Software Solutions
Introduction
It is perhaps obvious to say but software developers want to produce quality software and nobody makes mistakes on purpose (at least we hope). However, it is a fact that people are not perfect and will make mistakes.
How do we create a quality product when we know mistakes will be made? The first step, and sometimes the hardest, is to accept that mistakes will be made and then build tools, systems and procedures to help prevent or catch them.
So what can help us identify mistakes early so that we have opportunity to rectify them? One thing that we can all do is to perform regular code reviews. Code reviews are part of software testing and are intended to identify and avoid common types of coding errors.
There are two main methods of reviewing code:
- Peer Review
- Static Code Analysis Tools
Peer Review
Peer review is perhaps the simplest method of code review to implement as all it requires the developer who wrote the code and a developer to review it. However, in practice it is often not so easy. So why is peer review so hard? In my experience:
- People can find it hard to point out mistakes made by other people.
- People find it hard to accept criticism, even if mistakes have been made.
- Company managers to not provide adequate time, tools or support required for effective code review
Why is this? It is for the same reason that people make mistakes: people are not perfect!
Before we look in more detail of performing code reviews, lets first try to identify who’s code we should review.
- Developers with 1-5 years’ experience
- Experienced developers with 5+ years’ experience
- Software architects
Firstly, let’s consider what these people have in common; hopefully it is obvious, they are all people, people make mistakes and so all of them should have their code reviewed.
Not only will code reviews help identify bugs and areas of code that can be improved, they are an opportunity to share knowledge.
In addition to the obvious benefit of inexperienced developers learning from their experienced colleagues, there is opportunity for experienced developers to learn too. Experienced developers can become set in their ways and tackle the same problem in the same way. It is possible that a less experienced developer might know a better/newer technique! A software developer will often find bugs in their own code whilst talking another developer through what they have done.
How to Peer Review
Peer review involves one developer talking another developer (the reviewer) through the code under review, describing what has been implemented and how it should work. During the discussion, bugs and areas of code to be refactored will be identified. These can be fixed there and then or marked as to do at a later date.
Guidelines
- Reviews should not be performed by the developer who was responsible writing the code under review.
- Reviews should be frequent and informal
- Modules should always be reviewed before being integrated in to the system
- Consider what happens if a VI or function returns an error?
- Lookout for possible race conditions
- Review the block diagram style and consider whether the developer follows the adopted coding standard.
- Review if the code is efficient in terms of speed and/or memory usage
- Review whether the block diagram is easy to maintain.
- Use the code review to share knowledge and experience gained from other projects
- Do not be defensive if your code is under review.
- Review the code and not the developer who produced it!
I have highlighted the final two points as they are of utmost importance. Code reviews should not be about finding fault with individuals, rather they are an opportunity to identify defects, improve code and share knowledge. Blame is not productive!
Remember – Finding bugs in development is always better than a customer finding a bug in the field!
Static Code Analysis Tools
Static code analysis tools can be used analyse your source code files. In the LabVIEW development environment, the static code analysis tool is VI Analyzer.
VI Analyzer can be configured to analyse individual subVIs, a VI hierarchy or complete LabVIEW project. It can help identify common issues such as potential bugs and areas of code that break coding guidelines and best practice. For example, VI Analyser can be easily configured to identify all VIs within a project that do not have a VI description or lack block diagram comments, detect unhandled errors, or identify complex VIs that could be refactored to be more modular.
Once you have configured VI Analyser it can be easily run from the LabVIEW project environment, or can be automated to run, for example as part as a scheduled test and build process.
Tip: start with a simple VI Analyser configuration and then build on it as and when you need to. For example, to start with you might just want to look for VIs to do not have VI descriptions or block diagram comments, and VIs that have unhandled errors.
Conclusion
Code reviews are an important part of software testing and provide an opportunity to identify bugs and areas of code that can be improved, and provide an opportunity for developers to share knowledge.
Where possible manual code reviews should be frequent and informal, whilst developer tools such as VI Analyzer can complement the code review process and provide an opportunity for automation.
References and Further Reading
The following links provide more information on VI Analyzer:
VI Analyzer product download: http://sine.ni.com/nips/cds/view/p/lang/en/nid/209042
Why Use VI Analyzer Toolkit white paper: http://www.ni.com/white-paper/5046/en/
