Q: Code Review Checklist?

[Roman Suzi]

On Sat, 4 Aug 2001, Albert Brandl wrote:

>Roman Suzi wrote:
>
>> O! Just put motivating subject and you will have a long-long checklist. If
>> you just cite some items here from the original - you will get more in
>> return ;-)
>
>Have a look at http://cs.wwc.edu/~aabyan/435/PSP/CodeReviewGuide.html
>There you find the checklist used in Humphrey's book "A Discipline for
>Software Engineering".

Yes, already found that link. PSP seem to be some kind of personal
SEI CMM. AFAIK, there is only one or two companies which are toplevel
in CMM. IIRC, Motorola is/was one of them.

>Some items are irrelevant - in Python, you don't need to check whether
>pointers are initialized NULL, only deleted after new and always deleted
>after use if new.
>
>OTOH, the checklist requires you to e.g. test your logic operators:
>- Verify the proper user of ==, =, || etc
>- check every logic function for proper ()
>This would have caught your "<" vs ">" error.

No more than the statement: check your program logic.

>> Personally, I think that Python programmers do their checks while they
>> write code, because in Python you do not write that many LOC.
>
>I'm not sure what you mean. Do you suggest that Python is only
>used for tasks so simple that it's impossible to get it wrong? Or
>does "not that many LOC" mean that you split up your code in
>many little methods that can easily be verified?

I mean that in higher-level language errors tend to be logic ones, because
parts are larger and there is no need to worry about lists, hashes or to
reimplement them (which adds errors).

Also Python program of 100 lines is capable of doing what C program does
in 500 Lines Of Code. Some authors argue that even best programmers make 1
error per 7-10 LOC (I can't believe that, though. Maybe KLOC was meant).

Maybe I program too slowly, but I do not make so many errors.
Those error with "<" vs. ">=" was exception which is why I remembered
it ;-)

Usually my Python programs run first time correctly even syntactically.
(This still amazes me).

>> There is
>> Python Style Guide which will teach you how to write Pythonic Python
>> programs. Python idioms also help to keep programs readable. Applying
>> PyChecker could find some problems...
>
>In the PSP, there is a item called Standards: "Ensure that the code
>conforms to the coding standards". You are right: The Python Style
>Guide is a good starting point to define the standards.
>
>As for PyChecker: I've been using this tool for some time and like it very
>much. Unfortunately, automated tools can only detect certain classes of
>errors.

There is an interesting technique to estimate how many errors the program
has: add 10 errors to somebody's program and let it be debugged. If he
found 15 errors of which 5 were artificial, then it is possible to
estimate that there are other 15 errors still there.

>A general checklist should contain all kinds of error that are specific to
>Python and hard to find. It takes e.g. much time to realize that two
>variables reference the same object. It would be interesting to know
>if such a list is already "out there", but the response has not yet been
>overwhelming...
>
>> So, I can't think of any checklist to review my own code...
>
>Building a personal checklist is relatively easy: The next time you sit
>down and start the interpreter, note every error you stumble across.
>You'll soon see some patterns emerge, .e.g. spelling errors, infinite
>loops, off-by-one-errors, no "self" variable in the head of a function,
>logic errors, etc. - at least that's what I've experienced. Extract these
>patterns into a checklist and correct all problems you find _before_
>you start the interpreter.

But it is so much faster to let interpreter tell me syntactic errors and
obvious errors first. Then more accurate program checking could start.
Some parts of the program I even prefer to check by mathematical means.
For example, proper tarification when different tariff intervals are
crossed. The code is not large but it needed more than usual checks
because of it's importance.

Also, many errors occur when environment is not up to program's
expectation. I had several such mishaps this year, because some parameters
were changed without notice.

>        Best regards,
>
>                Albert
>

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Saturday, August 04, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Experience: a name everyone gives to his mistakes." _/