Code Inspections (Code Review)

Study Questions

1. What is code inspection?

2. What is the purpose of code inspection? What benefits might a software team gain from reviewing the code it develops?

3. How are code inspections connected to team learning (see Chapter 10)?

4. How is code inspection connected to program comprehension ?

5. How does code inspection differ from a review carried out by the individual (or pair) who wrote the code?

6. Suggest three reasons a software team would avoid code inspections.

7. Suggest three mechanisms/procedures that may ensure that software teams review their code on a regular basis.

8. There are companies that offer code inspection services. Find three examples of such companies on the Web. What kinds of services do they offer? What needs of other software houses do these code inspection companies fulfill? Why would a software house hire such a service instead of reviewing the code internally?

9. Read the article Group to Boost Code Review for Linux at http://zdnet.com.com/2100-1104-830255.html . How does the fact that Linux is Open Source software change its code inspection process?

This section focuses on code inspections and examines connections of code review to program comprehension and refactoring. All these processes are conducted in order to produce code of high quality.

In general, code inspection processes are exploration activities, conducted by the entire team, in order to recognize defects in the code and improve its readability. Inspection has several advantages over other scanning code activities.

First, it helps catch problems of different kinds in the code earlier in the development process. Here are three topics, out of many possible topics, that are important to find out early in the development process and that may come up during a code inspection process: the code does not do what it aims to do; the code is not readable (and some refactoring should be done to improve its readability); and there are better algorithms to implement the desired behavior. No matter what comes up from these options, some code improvements should be made.

Second, on the individual level, code inspection is an opportunity for everyone to be updated with what the others on the team develop, what has been accomplished so far, what strategies were adopted by other team members, and what common problems they faced. In addition, novices may learn from experienced team members .

Third, on the organizational level, because code inspection keeps knowledge within the company and leads to knowledge sharing, it supports the management of company knowledge (see Chapter 10).

Task  

Here are several questions to be asked during a code review process, suggested by Macadamian. ^[2]

General code smoke test: Does the code execute as expected? Do you understand the code you are reviewing? Has the developer tested the code?

Comments and coding conventions: Does the code respect the project coding standards? Are complex algorithms and code optimizations properly commented?

These questions are only a few examples taken from a suggested long list of topics to be addressed and questions to be asked. Because there are so many topics to think about, how can a code-inspection process be managed? How can we ensure that we do not skip any topic? Suggest a procedure for managing a code inspection process so that the important issues are not abandoned .

It is clear that code inspection supports program improvement and hence comprehension. This is achieved mainly by the feedback that all programmers get from the other team members during the code inspections. This feedback can refer to different aspects that may influence the code readability and comprehension. In the next subsection, we focus on refactoring ”the actual improving of the code. With respect to refactoring, we also discuss reasons that explain why and when programmers may avoid refactoring. Similar reasons may apply to the case of code inspections. What is common to these two activities is that they do not produce new code, but rather lead to the improvement of existing code. Thus, they contribute long-term benefits rather than support the fulfillment of short-term needs. Programmers who do not appreciate this long- term value may express resistance when asked to perform these activities.

Tasks  

1. How can pair programming (see Chapter 2) be conceived as code inspection?

2. Look at the Code Historian ( http://codehistorian.com/ ) and Glance ( www.glance.net/site/Home.asp ) Web sites. What features for code inspections do these tools offer?

3. If you have to design a computational tool for code inspection, what features would you include in it? Think about people s needs and activities during a code review process.

4. Ask several software developers about the code inspections habits and procedures used in their companies. Summarize these habits and procedures. Can they be improved?

5. Since code inspection is done by the entire team, it may raise social issues. Suggest several of these issues and explain them.

^[2] Macadamian states that it has made this checklist public, for the use of software development teams implementing code review as part of their process. Please feel free to use this checklist as it is, or to change it to customize a code review checklist that reflects your development style. For more information about Macadamian s code review processes and policies, read Part of Your Complete Breakfast: Code Review Is a Source of Essential Vitamins and Minerals at www.macadamian.com/codereview.htm#CommentsandCodingConventions .