Difference between revisions of "Slicer3:Style"
From NAMIC Wiki
Line 3: | Line 3: | ||
A few things to keep in mind: | A few things to keep in mind: | ||
− | * All C++ classes must conform to the style conventions of their parent classes. | + | * 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 [http://www.vtk.org/Wiki/VTK_Coding_Standards VTK Coding Standards] page. This means using the VTK two-space indent style (even if you don't like it!). | ** In most cases for Slicer Base, this means following VTK coding conventions including naming, indentation, and other issues discussed at the [http://www.vtk.org/Wiki/VTK_Coding_Standards 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 [[media:Style.pdf | Insight/Documentation/Style.pdf]] from the ITK distribution. | ** For command line modules implemented in ITK, follow the conventions defined in [[media:Style.pdf | Insight/Documentation/Style.pdf]] from the ITK distribution. | ||
Line 9: | Line 9: | ||
Highlights of the policies: | Highlights of the policies: | ||
− | * avoid acronyms in class and method names | + | * ''avoid acronyms in class'' and method names |
** some standard acronyms can be use (IJK, RAS, MRML, etc) | ** some standard acronyms can be use (IJK, RAS, MRML, etc) | ||
− | ** acronyms should be capitalized as a whole, not | + | ** ''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 | + | * use ''2 spaces for indentation'', not tabs |
− | * think carefully about the reusability of your class | + | * think carefully about the reusability of your class hierarchies |
* comment your code extensively | * 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. | Code that will be included in slicer must use CMake for cross platform building. |
Revision as of 12:27, 23 July 2007
Home < Slicer3:StyleGeneral 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.