Coding Style Guide

From GDCM Wiki
Jump to: navigation, search

Contents

C/C++

The coding style was largely inspired by such projects like VTK or ITK. See for instance ITK coding style guide, at [1]. And here for the VTK style guide [2]

Excerpt

We only have a few coding standards but they have proved very useful.

  • We strives to only put one public class per file. Some classes have helper classes that they use, but these are not accessible to the user.
  • The whole library is within the gdcm namespace to avoid clash with other libraries. when writing a Test and/or example for GDCM, do not import the whole gdcm namespace. Always explicitly use gdcm::
  • Class names and file names are the same. This makes it easier to find the correct file for a specific class.
  • We only use alphanumeric characters in names, [a-zA-z0-9]. So names like Extract_PixelData are not welcome. We use capitalization to indicate words within a name. For example CheckFileMetaInformation could be an instance variable or a class. We capitalize the first letter of a name. For local variables almost anything goes. Ideally we would suggest using same convention as instance variables except start their names with a lower case letter. e.g. checkFileMetaInformation.
  • We try to always spell out a name and not use abbreviations. This leads to longer names but it makes using the software easier because you know that the SetCheckFileMetaInformation method will always be called that, not SetCheckFMI or SetChkFMI or SetCFMI.
  • We try to keep all instance variables protected. The user and application developer should access instance variables through Set/Get methods.
  • Use "this" inside of methods only when required by the compiler to disambiguate (esp. for template member function from derived class).
  • Make sure your code compiles without any warnings with -Wall, in Release mode. (in Debug some assert are ok to report warnings, but should be avoided if possible).
  • The indentation style can be characterized as the "indented brace" style. Indentations are two spaces, and the curly brace (scope delimiter) is placed on the following line and indented along with the code (i.e., the curly brace lines up with the code). Example:
 if (TransferSyntax == ts)
   {
   return;
   }
 for (int i = 0; i < sq->GetNumberOfFragments(); i++)
   {
   frag = sq->GetFragment(i);
   [...]
   }
  • The header file of the class should (read: strive to) include only the superclass's header file.

Python

http://www.swig.org/Doc1.3/Python.html#Python_nn20

In Python, the static member can be access in three different ways:

>>> example.Spam_foo()    # Spam::foo()
>>> s = example.Spam()
>>> s.foo()               # Spam::foo() via an instance
>>> example.Spam.foo()    # Spam::foo(). Python-2.2 only


The latter should the one prefered, even if this is only available in python >= 2.2

External

Quotes

"If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

from http://en.wikiquote.org/wiki/Linus_Torvalds [wikiquote.org]



GDCM: [Welcome | Site Map]
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox