]> Creatis software - gdcm.git/blobdiff - Doc/Website/CodingStyle.html
Avoid warnings on C/C++ syle comments
[gdcm.git] / Doc / Website / CodingStyle.html
index 2b53165f6ae8297c6bf7494f031ee3f431839daf..1b0eb06fad83f94b7a94e6027161cd811e7fd997 100644 (file)
@@ -48,9 +48,9 @@
                                                                                 
 * Naming conventions:
  - Generalities:
-   In general, names are constructued by using case change to indicate
+   In general, names are constructed by using case change to indicate
    separate words, as in ImageDataSize (standing for "image data size").
-   Underscores are not used. Variable names are chosen carefully with the
+   Underscores are not used. Variable names are choosen carefully with the
    intention to convey the meaning behind the code. Names are generally
    spelled out; use of abbreviations is discouraged.
    [Note: abbreviation are allowable when in common use, and should be in
    Local variables begin in lowercase. There is more flexibility in the
    naming of local variables although they still should convey some
    semantics.
-                                                                                
+ - Naming function parameters:
+   Function parameters begin in lowercase. There is more flexibility in the
+   naming of function parameters although they still should convey some
+   semantics.
+                                                                                 
 * Classes:
  - Don't use the inline keyword when defining an inline function
    within a class definition.
       {
          GroupPixel = groupPixel;
       }
+ - Don't use trailing ';' in inline function definition.
+   use :
+   void A::SetGroupPixel( int groupPixel ){GroupPixel = groupPixel;}
+     NOT
+   void A::SetGroupPixel( int groupPixel ){GroupPixel = groupPixel;};
  - Do not repeat the virtual keyword when overriding virtual base methods
    in declaration of subclasses:
      class A
 * Special layout:
  - Avoid code mixed with comments on a single line. Instead, prepend the
    logical blocks of code with the concerned comments.
- - Use parantheses around conditions e.g. with an if statement:
+ - Use parentheses around conditions e.g. with an if statement:
       if ( someLocalVariable == 2 ) { ... }
  - Add spaces around parentheses, or braces. Use
-      if ( someLocalVariable == 2 ) { ClassMenber += 1; }
+      if ( someLocalVariable == 2 ) { ClassMember += 1; }
    and not
-      if (someLocalVariable == 2) {ClassMenber += 1;}
+      if (someLocalVariable == 2) {ClassMember += 1;}
  - Add spaces around each side of the assignement operator, and
    around binary operators used in boolean expression. Use
       someLocalVariable = ClassMember * 2;
    use C style comments ("/* ... */").
  - The last line of a file should terminate with "\n".
  - Returned arguments of methods and functions should not be wrapped with
-   parantheses. Use
+   parentheses. Use
       return iter->second;
    but do not use
       return ( iter->second );
    The Doxygen open-source system is used to generate on-line documentation.
    Doxygen requires the embedding of simple comments in the code which is in
    turn extracted and formatted into documentation. See
-      http://www.stack.nl/ dimitri/doxygen/
+      http://www.stack.nl/~dimitri/doxygen/
    for more information about Doxygen.
  - Documenting a class:
    Classes should be documented using the class and brief doxygen commands,
          bool Readable = false;
                                                                                 
          /// \brief The number of lines of the image as interpreted from
-         /// the various elements encountered at header parsing.
+         ///        the various elements encountered at header parsing.
          int NumberOfLines = -1;
                                                                                 
          /// Predicate implemented as accessor around \ref Readable.
        * \brief  Within the Dicom Elements (parsed with the public and private
        *         dictionaries), look for the element value representation of
        *         a given tag.
-       * @param  group Group number of the searched tag.
+       * @param  group  Group number of the searched tag.
        * @param  elem Element number of the searched tag.
        * @return Corresponding element value representation when it exists,
        *         and the string "gdcm::Unfound" otherwise.
       T *foo = 0;
    and not
       T* foo = 0;
+   nor
+      T * foo = 0;
  - Assume T is a given type. When declaring or defining with the
    "reference to T" notation, the & character must be adjacent to
-   the variable and not the type. That is use
+   the variable and not the type. That is use :
       T &foo = 0;
    and not
       T& foo = 0;
-   This is the common notation, not a 'gdcm special' notation.
-   (doxygen will not have any longer to correct)
+
+   (Doxygen will not have any longer to correct)
 
  - Always define a typedef for a new type and be consistent in usage.
    Use
-      typedef HeaderHeaderPointer;
+      typedef Header *HeaderPointer;
       HeaderPointer MyHeaderPointer;
  - One notorious counter example for non using C style inclusion concerns
    exact-width integers (since there seem to be no equivalent for C++).