| |
|
It has been long noticed that when noone looks at a programmer's code, the programmer very often leaves small niceties undone, things such as consistent style, improving clarity, etc. When the code will be reviewed by someone else, programmers are motivated to polish their code to a higher shine.
| Table of contents |
|
2 Informal inspection 3 Open source 4 Studies 5 See also |
There are a variety of formal inspection methodologies.
In most, code is read by a group, often 5 to 9 people,
and they discuss the meaning and structure of it.
Usually, there is a checklist of things to look for.
IBM was reknowned for it. NASA was reknowned for it.
One disadvantage is that inspections usually take place after
the code is complete, which means that flaws in the design
which are discovered and fixed may require substantial rework.
This is frustrating for all.
Another disadvantage is that this formal inspections are confrontational.
The programmer who is undergoing the inspection feels picked on
and rarely does anyone say anything positive about the code.
This tends to increase alienation by programmers.
This include pair programming, where every line of code is reviewed
by a partner as it is being written.
One advantage of this is that the design of the software is discussed
while the software is being written, which means that the design is
also being inspected.
Another advantage is that the review is cooperative, in that both
programmers have a stake in producing good code.
Open source code is not really even an informal inspection, but
it has some interesting results. When projects are worked on
collaboratively, such as Linux or gcc the code recieves
excellent peer review. However, most open source projects do not
get much attention, and the peer review may not actually exist
for much of the open source code.Formal inspection
Informal inspection
Open source