Slicer3:Style

General Considerations

A few things to keep in mind:

• All C++ classes must conform to the style conventions of their parent classes.
  • In most cases for Slicer Base, this means following VTK coding conventions including naming, indentation, and other issues discussed at the VTK Coding Standards page. This means using the VTK two-space indent style (even if you don't like it!).
  • For command line modules implemented in ITK, follow the conventions defined in Insight/Documentation/Style.pdf from the ITK distribution.
  • Libraries (such as Teem, zlib, etc) may follow their own coding styles, and be wrapped with in classes with the appropriate styles.

Highlights of the policies:

• avoid acronyms in class and method names
  • some standard acronyms can be use (IJK, RAS, MRML, etc)
  • acronyms should be capitalized as a whole, not by first letter (e.g. RASToIJK is correct -- RasToIjk is not correct )
• use 2 spaces for indentation, not tabs
• think carefully about the reusability of your class hierarchies
• comment your code extensively
• do not leave dead code in the source files. Large blocks of commented out code makes the source file hard to read. Instead, include a comment that points to a previous revision number in svn that has the previous revision you are removing.

Code that will be included in slicer must use CMake for cross platform building.

Licensing

Code is released under the slicer license.

All NA-MIC funded software, data, documentation, and other materials should include the NIH Roadmap acknowledgement.

Please add acknowledgements for any and all grants that helped fund your development work. See Slicer3:Acknowledgements for lists of grants and grant numbers.