Seamonkey Code Reviewer's Guide
If you code review someone else's changes, you are on the hook with them to see that those changes are good. Here is a sampling of questions you should be asking if you are asked to review someone else's code.
- Am I the right person to be reviewing this code?
- What was the original problem you were trying to solve or bug you
were trying to fix?
- was there a bug report on the problem?
- can we look at the bug report?
- did the nature or scope of the of the problem evolve during the investigation? how?
- were there any trade-off's (e.g. size/speed, UI completeness/simplicity) that you considered or made in constructing the fix?
- Show me the code
- Let me see the new code
- Let me see the diffs
- Tell me how you have tested the code
- Show me a simple test case
- Show me a bigger test case that shows you haven't broken anything
- What are the error conditions this code might experience?
- What could this change have possibly broken?
- What effects might this change have on size, speed, or memory use?
- Have you checked for leaks or premature free memory conditions?
- Have you checked for race conditions, error conditions, or infinite loops?
- Where are all the places this function is called from?
- Could anyone or anything depend on the old broken behavior?
- Does the change consider platform issues like 64 bit ints, does this code work?
- Do the changes affect a single platform, or are they cross-platform?
- What other machines have you compiled and tested this code on?
- Have you check the code for possible compiler quirks
- Is this the right time to be making this change?
- Is this a fix to a fix, or in a high risk area?
- Is there a simpler change which solves the problem in all the important cases?
- Is there another release coming where this change would be more appropriate?
Remember, a code reviewer is not a friend. A good code reviewer can feel like your worst enemy.