Difference between revisions of "Slicer3:Style"
From Slicer Wiki
| (2 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
** Libraries (such as Teem, zlib, etc) may follow their own coding styles, and be wrapped within classes with the appropriate styles. | ** Libraries (such as Teem, zlib, etc) may follow their own coding styles, and be wrapped within classes with the appropriate styles. | ||
| − | Highlights of the policies: | + | Highlights of the [[Slicer3:Style_and_Conventions|policies and conventions]]: |
* ''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) | ||
| Line 36: | Line 36: | ||
* Code is not considered complete without the following: | * Code is not considered complete without the following: | ||
** [[Slicer3:Testing|Tests]] | ** [[Slicer3:Testing|Tests]] | ||
| + | ** [[Documentation|Documentation]] | ||
** [[Slicer3.4:Training|Tutorials]] | ** [[Slicer3.4:Training|Tutorials]] | ||
* Also, please have a support plan for the future. If you will not be willing to respond to future questions about the code, then find someone who is willing or don't submit the code. | * Also, please have a support plan for the future. If you will not be willing to respond to future questions about the code, then find someone who is willing or don't submit the code. | ||
| + | |||
| + | Review [[Documentation-3.5-Rons-Rules|Ron's requirements for a good module]]. | ||
Latest revision as of 13:14, 15 April 2010
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 within classes with the appropriate styles.
Highlights of the policies and conventions:
- 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 acknowledgment.
Please add acknowledgments for any and all grants that helped fund your development work. See Slicer3:Acknowledgements for lists of grants and grant numbers.
Contributions
Bug fixes and ports to new platforms are always welcome from anyone in the slicer community.
People interested in contributing new functionality should consider the following:
- The Slicer3 Extension Modules are the recommended way to get new application functionality into slicer.
- Code is not considered complete without the following:
- Also, please have a support plan for the future. If you will not be willing to respond to future questions about the code, then find someone who is willing or don't submit the code.
