7.11 Code Reviews

   

The prospect of having someone trawl through your code looking for defects is enough to strike fear into the heart of any developer. Done correctly, many defects can be uncovered at an early stage, thus saving time and money. Done badly , the process can degenerate into a painful exercise, leaving individuals bitter and twisted.

As a brief example, consider the situation where you have a problem in your code that you can't track down, so you ask a colleague to have a look with you. A couple of minutes into explaining the problem and viola, you've spotted it and your colleague hasn't even uttered a word.

So what do we hope to achieve from code reviews? It certainly shouldn't be the stage for the reviewers to impress on the whole world how good they are at the expense of everyone else. What we hope to achieve is to spot problems early, but also ensure that all concerned are following the same style, processes, design, and implementation methodologies. We can collectively call this our coding standards. An often indirect gain from reviews is communication and learning. It more often than not transpires that a new technique or method of doing something comes out at a review, which ordinarily would not have been communicated to everyone else working on the project.

We also feel that it is important that everyone on a team has the chance to become a reviewer. This is good personal development, but also will inhibit any "them and us" feelings since everyone on both sides is participating.

There are several different kinds of code reviews, but walk-throughs , code reading, and inspections cover most. They are all similar, but inspections are the best defined. Without giving a complete discussion of a software inspection, the exercise should include the following:

Each member of the review team should be given a copy of the software to be reviewed sometime before a formal meeting is held. This will give the reviewer the chance to go through the code and make notes on actual or anticipated defects.

Each reviewer is fully aware of the design and objectives of the software and the project. If this is not the case, then the reviewers are given enough time to familiarize themselves .

Each reviewer will have a set of guidelines of things to review, which could be a checklist. The idea is to focus everyone's effort.

The person who is having his or her code reviewed should have adequate time to review the comments made.

When the code is ready, a meeting should be held and the comments discussed. It is not necessary to come up with fixes there and then, but to move along at a brisk pace and agree on whether the comments are justified or not. It could be the case that a comment made by a reviewer is an observation that does not constitute any action, once the developer has explained the reasoning behind the code or direction taken.

Someone should lead the entire effort, especially the meeting. This person is generally called the moderator.

Someone else should document the problems raised and any further comments raised.

At the end of the review, a document should be produced as soon as possible that details all the faults and bugs found. This will provide the action list.

The developer then goes away and addresses the points raised.

Someone should then confirm that the action list has been completed.

In our opinion, the entire process should be carried out in as lighthearted manner as seems fit. Getting a group of developers to buy into having their code reviewed is hard enough, but then to make it a formal stage for public execution means that everyone involved will resist as much as possible. In the end, this means the whole review system will die and no benefit will be gained .

The published statistics for the payback from inspections are shocking. It has been reported that having inspections can catch 60 “90% of defects ”now that has got to be a good thing. Not only that, but if you know your code is going to be reviewed, then you are less likely to take shortcuts because as you know they probably will be spotted. The sum total of this is better quality.

To end this short section on inspections, you will find a checklist for inspecting LabVIEW code. LabVIEW is probably far easier to review than text-based languages. Its graphical nature should mean that cryptic- and syntax-like problems cannot lurk hidden within the depths of any code.

LabVIEW Code Inspection Checklist

  • All code runs without reported errors.

  • Front panels are well laid out, and inputs and outputs clearly defined.

  • All user - facing front panels and user interfaces are clear and obvious as to their function.

  • Each icon is meaningful.

  • Each VI name is meaningful.

  • Each component exhibits strong cohesion and is loosely coupled .

  • All interfaces to components are clearly defined.

  • Each VI has the description section filled in.

  • Each diagram for a VI is clearly laid out and labeled.

  • The diagram is not so large as to inhibit reading and understanding.

  • The developer has reused available code where applicable .

  • There are no global variables within the system code, except where formally agreed.

  • Preconditions and postconditions are used for all critical VIs.

  • All enumerated types contain meaningful entries.

The checklist could go on and on. There could also be project-specific items added or whatever else you feel is going to cut down on the chance of problems arising later. Ensure that problems are fed back in the system.


   
Top


A Software Engineering Approach to LabVIEW
A Software Engineering Approach to LabVIEW
ISBN: 0130093653
EAN: 2147483647
Year: 2003
Pages: 66

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net