The Art Of Software Development (part 3): Coding To A Plan - A Quick Inspection (Page 6 of 7 )
In order to ensure that a project is being implemented correctly from a technical standpoint, it's critical to have frequent code inspections and peer reviews. These reviews are a project manager's basic mechanism for validating the design and implementation of a software application, and play a significant role in catching and resolving potentially serious errors at an early stage. Code inspections also help enforce consistency between the different components of a software project, and play an important role in making novice developers aware of their mistakes, and teaching them how to correct the deficiencies.
Code review is used to verify the logic, control flow and interfaces of a particular piece of code, and should be *not* be performed by the original author of the code. Rather, a code review should be performed by one or more team members or senior developers, and the results should be disseminated to the code author, together with notes on how the errors discovered may be resolved. The choice of code reviewer(s) should be made keeping in mind the characteristics and requirements of the code that is to be reviewed - it makes very little sense, for example, to have a database specialist inspect encryption algorithms.
There are some basic guidelines to be kept in mind during the code inspection process, and some fundamental questions that a reviewer should ask. Here's a brief list:
- Is the code clearly commented? Is the comment style consistent and readable? Are nested code blocks clearly indented? Is the specified coding standard followed?
- Are variables initialized before they are used?
- Are any variables duplicated?
- Are variables names descriptive? Is there a clear demarcation between global and local variables? Are constants properly declared?
- Do all loops have an exit condition?
- Are all function inputs used? Are all required function outputs produced?
- Do functions adequately check for invalid or out-of-bound inputs? What happens if you provide a function with a value that is out of range, or in an unexpected format?
- Are function return values checked for errors, or for null returns?
- Are all opened file handles closed? Are all created objects destroyed?
- Are multiple processes acting on a single file? Does the code include file locking or process queuing mechanisms to avoid data corruption in such cases?
- Is the database schema normalized? Does it contain redundant data?
- Are SQL queries optimized? Are all the fields requested in a recordset actually being used?
- Is user input being thoroughly validated before being processed?
- Are all errors handled in a standard manner? Are error messages descriptive and helpful?
- If a component was specifically designed for reuse, is there anything hardwired into its internals that would prevent it being used in this manner?
Once the code review is complete, a decision must be made as to whether the code is acceptable as is and can proceed to unit testing, or if modifications and a further review is required. If further review is required, the project schedule should be updated accordingly.
In order for a code inspection to be effective, it's important that the process be a participatory one, and that it focus on locating and correcting mistakes rather than on apportioning blame. A good code review session can leave its participants feeling like they learned something; a bad one can make them want to fling themselves off the nearest skyscraper. If you're the one inspecting the code, remember to keep your criticism constructive - and if you're the poor guy in the hot seat, try and leverage off the ideas and knowledge of the more experienced programmers in your group.
Next: Homework >>
More Practices Articles
More By Vikram Vaswani, (c) Melonfire
/ 5 
