Welcome to Part 3) of the BSP Software ‘Code Review’ series
Part 1) Author and Review Preparation
Part 2) Readability
Code Review Aspects
Peter Gabris, MD of BSP Software Inc
Part 3) Structure
The structure of the code has to correlate to the coded algorithm. Basic structures are
- Sequence,
- Condition,
- Loop,
- Procedure.
Statements in a sequence should have the same indentation and should be organized into logical groups by an occasional single empty row and perhaps a comment.
Case (select/switch) conditions should be used instead of multiple if-else conditionals if possible. Case (select/switch) conditions should not be nested nor contain other conditionals or loops. A conditional branch should not be longer than a half of the page (screen).
Loop conditions should be clearly visible at the loop initialization or exit. When the initial or final value of the loop counter is a result of preceding calculation, its name should clearly indicate where it comes from. The loop counter should not be modified in the loop.
A procedure should serve a single well defined purpose. The name of the procedure should clearly express the purpose. A name CalculateTotalSales states the purpose while a name LoopThoughArray is useless; it tells you what you can see from the code anyway. Side effects of a procedure should be obvious from the name, like ClearClientFormFields. Functions should never have any side effects. The length of a procedure should be shorter than a page with an exception of a sequence that could not be replaced by a loop or data.
Object should be declared / instantiated close to the place where it is needed. Some languages require declarations at the beginning of a unit – one more reason to keep units short. Object should be always created and discarded in the same procedure. Object should be discarded as soon as it is not needed.
Code Review continues in Part 4) Algorithmic soundness
Feel free to leave any questions or comments below