It is a well-known fact in the software industry that bugs found later in the design cycle are more expensive to correct than those found earlier. In the worst case, the product ships with uncorrected bugs that require a maintenance release, costly in-the-field upgrades and possibly can damage the reputation of the company.
One of the most cost-effective ways of eliminating bugs very early in the development cycle is to perform source code reviews. In this exercise colleagues study each other’s code with an eye towards finding coding problems. The upfront investment in time and effort saves time and expense later on.
Code reviews can be applied with great flexibility during the development cycle. They can be performed on the complete or partial project, and can be done at various times such as prior to Alpha and Beta releases, prior to system testing, or at other useful milestones. Code reviews can target different types of problems such as compliance with the design, coding style compliance, maintainability, portability, or logic errors, etc.
Atollic TrueSTUDIO is one of very few C/C++ IDE’s to integrate features for source code reviews and code review meetings. With TrueSTUDIO, you can easily create and run one or more source code reviews; thus potentially increasing the software quality a lot.
Since code review requires intensive study of the code, and since the best code management tool is the IDE, I think it makes good sense to put code review tools directly into the IDE not only for convenience and ease of use, but to facilitate this practice by lowering barriers to its use. The easier it is to do, the less excuse there is not to employ this proven technique of improving software quality.
Once colleagues have reviewed each other’s source code individually, the reviewers then get together in a code review meeting where all review comments are discussed, and action items are decided on for each review comment. These include classification of issues such as “valid and must be fixed”, “invalid” or “valid but fix later.”
The loop is closed by the review comments being corrected according to the decisions made in the code review meeting. Each developer or reviewer gets a work-list with code review comments he was appointed to correct. Using this methodology, code reviews can be run easily with the benefit of both improved software quality and skills spread between developers in the team.
Closing the loop of the code review involves feedback of the issue classifications to individual developers in the form of a work-list of items to be addressed. Once developers have a chance to implement their modifications, they mark their progress using the code review tools in the IDE. Team leaders then have information at their disposal about what issues were addressed, and by whom. This kind of information reduces project overhead, saves time and results in inherently superior software quality and reliability.
For more information on source code reviews and code review meetings, read this whitepaper on code reviews: