Slicer3:Style and Conventions - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T18:04:20Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Marianna: Unprotected "Slicer3:Style and Conventions"

2008-05-20T17:49:03Z

Unprotected "Slicer3:Style and Conventions"

Marianna: Replacing page with ''''Note:''' We are migrating this content to the slicer.org domain - The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:Style_and_C...'

2008-05-20T17:48:52Z

Replacing page with '<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:Style_and_C...'

Andy: Update from Wiki

2006-12-18T13:16:38Z

Update from Wiki

Andy: Update from Wiki

2006-12-18T13:16:37Z

Update from Wiki

New page

= Coding Conventions =

* Code that inherits from VTK classes should follow VTK coding conventions for naming, intentation, etc.
* This will simplify debugging of code that relies on the VTK object model, command observer structures, and other key VTK elements.

== Naming ==

* Acronyms should be written in all CAPS.
** For example: '''RASToSlice''' not RasToSlice
** '''vtkMRML''' not vtkMrml
* Words should be spelled out and not abreviated
** For example: '''GetWindow''' not GetWin
* Local variable should start with a lower case.
** For example:

void vtkSlicerSliceLogic::SetForegroundLayer(vtkSlicerSliceLayerLogic *ForegroundLayer)

should be

void vtkSlicerSliceLogic::SetForegroundLayer(vtkSlicerSliceLayerLogic *foregroundLayer)

* Member variable should start with a capital letter, and in implementation should be used in conjunction with 'this->' convention
** For example

class Node {
Object &Foo();
Object Bla;
};
Object& Node::Foo() {
return this->Bla;
}

* '''Module GUI classes''' (those derived from vtkSlicerComponentGUI or vtkSlicerModuleGUI, which contain widgets, GUI building and mediator methods) should all have the prefix ''vtkSlicer'' and the suffix ''GUI''.
** For example: vtkSlicerVolumesGUI or vtkSlicerFiducialsGUI
* For now, '''widgets''' derived from vtkKW classes should end in ''Widget'', ''Editor'', or ''Viewer'' (this convention may change)
** For example: vtkSlicerSliceViewerWidget or vtkSlicerWindowLevelThresholdEditor

== Comments ==

* include extensive comments in the header files
* '''keep the comments up to date as the code changes'''
* use the keyword '''TODO''' to flag spots in the code that need to be revisited

== Library Dependencies ==

* MRML classes should only depend on vtk and itk
* Logic classes depend on MRML to store state
* Logic classes should encapsulate vtk and itk pipelines to accomplish specific slicer tasks (such as resampling volumes for display)
* GUI classes can depend on MRML and Logic and KWWidgets
* Wherever possible, GUI functionality should be encapsulated as subclasses of vtkKWCompositeWidget with no dependence on MRML or Logic
* GUI classes serve as the mediator between the Logic and MRML classes on one side and the 'pure UI and visualization' code in KWWidgets and VTK on the other side.

== GUI style guidelines (just a start!...) ==

* Use grooved relief for frames to clarify functional groupings of widgets; otherwise use no (flat) relief.
* Wherever possible, use xpad = ypad = 2 between widgets; use xpad = ypad = 1 to tightly group related widgets.
* Capitalize the first letter in any text specified for a label or button.
* Try to use brief phrases when specifying text for a label or button rather than using sentences or sentence fragments ( use "Load Volumes" instead of "Choose a volume to load")
* Provide fully descriptive tool tips with each widget defined.
* Slicer's main GUI panel's dimensions are defined in slicer3/Base/GUI/vtkSlicerGUILayout.cxx; currently the GUI panel minimum width is set to 300 pixels; widgets wider than this will be clipped in Slicer's default window configuration.

== Development Practices ==

* While developing code, enable VTK_DEBUG_LEAKS in your vtk build and be sure to clean up and leaks that arise from your contributions.

= Coordinate Systems =

* World space for 3D Views is in RAS (Right Anterior Superior) space
* All units are expressed in Millimeters (mm)

← Older revision		Revision as of 18:04, 10 July 2017
Line 1:		Line 1:
−	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [~~http~~://www.slicer.org/~~slicerWiki/index.php~~/Slicer3:Style_and_Conventions here]</font></big>	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:Style_and_Conventions here]</font></big>

← Older revision		Revision as of 17:48, 20 May 2008
Line 1:		Line 1:
−	~~= Coding Conventions =~~	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:Style_and_Conventions here]</font></big>
−
−	* Code that inherits from VTK classes should follow VTK coding conventions for naming, indentation, etc. See http://www.vtk.org/Wiki/VTK_Coding_Standards for details.
−	* This will simplify debugging of code that relies on the VTK object model, command observer structures, and other key VTK elements.
−	* Use STL where you can, but follow the VTK guidelines here http://www.vtk.org/Wiki/VTK_FAQ#Can_I_use_STL_with_VTK.3F
−	* Configure your text editor to do VTK style indentation:
−	** Emacs: http://www.vtk.org/Wiki/Elisp_Code_for_VTK-Style_C_Indentation
−	** Vi/Vim: http://wiki.na-mic.org/Wiki/index.php/User:Pieper
−	** Visual Studio: http://www.vtk.org/Wiki/VTK_FAQ#How_do_I_get_my_C.2B.2B_code_editor_to_do_VTK-style_indentation.3F
−
−	~~== Naming ==~~
−
−	* Acronyms should be written in all CAPS.
−	** For example: '''RASToSlice''' not RasToSlice
−	** '''vtkMRML''' not vtkMrml
−	* Words should be spelled out and not abreviated
−	** For example: '''GetWindow''' not GetWin
−	* Local variable should start with a lower case.
−	** For example:
−
−	~~void vtkSlicerSliceLogic::SetForegroundLayer(vtkSlicerSliceLayerLogic *ForegroundLayer)~~
−
−	~~should be~~
−
−	~~void vtkSlicerSliceLogic::SetForegroundLayer(vtkSlicerSliceLayerLogic *foregroundLayer)~~
−
−	* Member variable should start with a capital letter, and in implementation should be used in conjunction with 'this->' convention
−	** For example
−
−	~~class Node {~~
−	~~Object &Foo();~~
−	~~Object Bla;~~
−	};
−	~~Object& Node::Foo()~~
−	{
−	~~return this-~~>~~Bla;~~
−	}
−
−	* '''Module GUI classes''' (those derived from vtkSlicerComponentGUI or vtkSlicerModuleGUI, which contain widgets, GUI building and mediator methods) should all have the prefix ''~~vtkSlicer~~'~~' and the suffix ''GUI''.~~
−	** For example: ~~vtkSlicerVolumesGUI or vtkSlicerFiducialsGUI~~
−	* For now, '''~~widgets''' derived from vtkKW classes should end in ''Widget'', ''Editor'', or ''Viewer'' (~~this ~~convention may change)~~
−	** For example: vtkSlicerSliceViewerWidget or vtkSlicerWindowLevelThresholdEditor
−
−	~~== Comments ==~~
−
−	* include extensive comments in the header files
−	* '''keep the comments up to date as the code changes'''
−	* use the keyword '''TODO''' to ~~flag spots in~~ the ~~code that need to be revisited~~
−
−	~~== Library Dependencies ==~~
−
−	* MRML classes should only depend on vtk and itk (not Slicer Logic or GUI)
−	* Logic classes depend on MRML to store state
−	* Logic classes should encapsulate vtk and itk pipelines to accomplish specific slicer ~~tasks (such as resampling volumes for display)~~
−	* GUI classes can depend on MRML and Logic and KWWidgets
−	* Wherever possible, GUI functionality should be encapsulated as subclasses of vtkKWCompositeWidget with no dependence on MRML or Logic
−	* GUI classes serve as the mediator between the Logic and MRML classes on one side and the 'pure UI and visualization' code in KWWidgets and VTK on the other side.
−
−	~~== GUI style guidelines (just a start!...) ==~~
−
−	* Use grooved relief for frames to clarify functional groupings of widgets; otherwise use no (flat) relief.
−	* Try to allow Slicer's Theme to prescribe look and feel; only override if necessary.
−	* Wherever possible, use xpad = ypad = 2 between widgets; use xpad = ypad = ~~1 to tightly group related widgets.~~
−	* Capitalize the first letter in any text specified for a label or button.
−	* Try to use brief phrases when specifying text for a label or button rather than using sentences or sentence fragments ( use "~~Load Volumes~~" ~~instead of "Choose a volume to load")~~
−	* Provide fully descriptive tool tips with each widget defined.
−	* Slicer's main GUI panel's dimensions are defined in slicer3/~~Base~~/~~GUI~~/~~vtkSlicerGUILayout.cxx; currently the GUI panel minimum width is set to 300 pixels; widgets wider than this will be clipped in Slicer's default window configuration.~~
−	* Event(keyboard accelerators and mouse actions) binding conventions are described [[Slicer3:~~EventBindings\|~~here. ]]
−
−	~~== Development Practices ==~~
−
−	* While developing code, enable VTK_DEBUG_LEAKS in your vtk build and be sure to clean up any leaks that arise from your contributions.
−
−	~~= Coordinate Systems =~~
−
−	* World space for 3D Views is in RAS (Right Anterior Superior) space
−	* All units are expressed in Millimeters (mm)

← Older revision	Revision as of 17:49, 20 May 2008
(No difference)

@@ Line 1: / Line 1: @@
 = Coding Conventions =
-* Code that inherits from VTK classes should follow VTK coding conventions for naming, intentation, etc.
+* Code that inherits from VTK classes should follow VTK coding conventions for naming, indentation, etc. See http://www.vtk.org/Wiki/VTK_Coding_Standards for details.
 * This will simplify debugging of code that relies on the VTK object model, command observer structures, and other key VTK elements.
 == Naming ==
@@ Line 27: / Line 32: @@
     Object Bla;
   };
-  Object& Node::Foo() {
+  Object& Node::Foo()
     return this->Bla;
+  }
@@ Line 44: / Line 50: @@
 == Library Dependencies ==
-* MRML classes should only depend on vtk and itk
+* MRML classes should only depend on vtk and itk (not Slicer Logic or GUI)
 * Logic classes depend on MRML to store state
 * Logic classes should encapsulate vtk and itk pipelines to accomplish specific slicer tasks (such as resampling volumes for display)
@@ Line 54: / Line 60: @@
 * Use grooved relief for frames to clarify functional groupings of widgets; otherwise use no (flat) relief.
 * Wherever possible, use xpad = ypad = 2 between widgets; use xpad = ypad = 1 to tightly group related widgets.
 * Capitalize the first letter in any text specified for a label or button.
@@ Line 59: / Line 66: @@
 * Provide fully descriptive tool tips with each widget defined.
 * Slicer's main GUI panel's dimensions are defined in slicer3/Base/GUI/vtkSlicerGUILayout.cxx; currently the GUI panel minimum width is set to 300 pixels; widgets wider than this will be clipped in Slicer's default window configuration.
 == Development Practices ==
-* While developing code, enable VTK_DEBUG_LEAKS in your vtk build and be sure to clean up and leaks that arise from your contributions.
+* While developing code, enable VTK_DEBUG_LEAKS in your vtk build and be sure to clean up any leaks that arise from your contributions.
 = Coordinate Systems =