Q: Code Review Checklist?

[Albert Brandl]

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".

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.

> 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?

> 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.

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.

        Best regards,

                Albert