Iteration Code Reviews
Code reviews for iterations 1 to 6 can be found here: Iteration Code Reviews
Code Review Check List
The following is the list of coding style issues that must be verified on every class and file during a code review.
Please also refer to the IGSTK Style Guide (PDF)
- Filename must match class name
- All files must have the copyright notice at the top
- #define for class name in the headers
- Brief class doxygen description (Must be a sentence terminated in a period ".")
- namespace igstk
- Complete class doxygen description
- Constructor and Destructor must be protected if the class use SmartPointers
- Operator= and Copy constructor must be declared private and not be implemented if the class use SmartPointers
- No acronyms in class name or method names
- no unnecessary headers #included
- If possible, vtk classes should have a forward declaration instead of including their header.
- Justify every public method
- All member variables must be private
- Typedefs that are not needed for the public API must be declard in the private/protected section as appropriate.
- 100% code coverage (see dashboard)
- All 'non-const' method must justify why they are not 'const'
- In classes with StateMachine the method ProcessInputs() should only be called from Request methods.
- All classes derived from itk::Object or vtkObject must have a PrintSelf method
- All classes deriving from igstk::Object must have one (and only one) of the following macros
- Any information that is printed or displayed has to be legible to human eyes
- Maximum line length should be 78 chars
- If the class has a state machine,
- The state machine diagram needs to be exported by adding an entry to igstkStateMachineExportTest
- State Machine diagram needs to be added to the doxygen documentation. To do this, \image with the name of the state machine diagram needs to be added to the detailed description of the class (documentation in the header) .