ITK/Code Review Check List: Difference between revisions

From KitwarePublic
< ITK
Jump to navigationJump to search
Line 17: Line 17:
* Justify every public method
* Justify every public method
* All member variables must be private
* All member variables must be private
* Use Set Get Macros
* Use Set/Get Macros (macros should call Modified to ensure pipeline data is updated)
* If deriving from itkObject
* If deriving from itkObject
** Use New macro
** Use New macro

Revision as of 21:04, 7 July 2009

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.

  • Filename must match class name
  • All files must have the Copyright Header at the top.
  • #define for class name in the .h and .txx files. __classname_h and __classname_txx
  • Brief class doxygen description
  • namespace itk
  • Complete class doxygen description
  • Classes that use SmartPointers must have
    • Constructor/Destructor protected
    • Copy Constructor : private and not implemented
    • Operator= : private and not implemented
  • No acronyms in class name or method names
  • no unnecessary headers #included
  • Justify every public method
  • All member variables must be private
  • Use Set/Get Macros (macros should call Modified to ensure pipeline data is updated)
  • If deriving from itkObject
    • Use New macro
    • declare SmartPointer<T> as Pointer
    • declare SmartPointer<const T> as ConstPointer
    • declare Self
    • declare Superclass
    • use TypeMacro
    • Have PrintSelf() method and print all the member variables
  • 100% code coverage (see dashboard)
  • All 'non-const' method must justify why they are not 'const'
  • Any information that is printed or displayed has to be legible to human eyes
  • Respect Coding Style as specified in the document Insight/Documentation/Style.pdf
  • Must pass the test of KWStyle
  • [Style] In the .txx files of template classes, the first 5 lines in the declaration of methods should be:
    • 1) template
    • 2) return type
    • 3) class name
    • 4) ::method name
    • 5) the opening bracket

For example:

 template <  template_arguments >
 return_type
 classname< template_arguments >
 ::methodsName( method_arguments )
 {
   // indentation of two spaces
   // for the first line of code
   int k = 0;
 }

In many cases line (2) uses a trait from the templated class and therefore becomes:

 typename classname< template_arguments >::trait

Running KWStyle

In a single file

  KWStyle -xml ITK.kws.xml itkQuadEdgeMeshTest1.cxx -V 

In all the repository

  make StyleCheck



ITK: [Welcome | Site Map]