|
|
|
Books are full
of advice on how to conduct the reviews and here are a few samples.
|
|
|
|
If you are
reading someone else’s code then it should not be difficult to understand
because of formatting differences. Get
everyone to write in a reasonably similar style or get programs that will
convert between styles.
|
|
|
|
The code that I
put on the web does not satisfy this guideline. That code was exported as RTF text with
syntax highlighting. I added line
numbers with Word, but when Word converted to HTML, the line numbers were
lost. Furthermore, the paper version
that I’m handing out is only in black and white. Sorry.
|
|
|
|
In this red book
they explain how reviews helped achieve clean compiles. This was very important in the days when
punch cards were used, but today the cost of having humans check for syntax
errors is much higher than having the compiler do it.
|
|
|
|
In general, the
code should be understood by everyone before the review begins. This is not very important in the case of
this toy example code.
|
|
|
|
The book
recommends against correcting problems during the review. It probably isn’t a good idea to have
someone making code changes while lots of other people are waiting.
|
|
|
|
Lastly, don’t
tread on people’s feelings. One way to
do this is to identify good things in the code. This should also encourage others to adopt
good habits.
|
|
|
|
|
|
|
