STYLE: No need to use c string

[gdcm.git] / DEVELOPPER

diff --git a/DEVELOPPER b/DEVELOPPER
index 3f01c29ec3bcf2148c890f6e42edba9ad36d1156..37af3d44ff705aba8fcbae223ecf9599344bb49b 100644 (file)
--- a/DEVELOPPER
+++ b/DEVELOPPER
@@ -20,6 +20,11 @@ The following comments are intended for core gdcm developpers.
         -- GDCM_VTK When this option is on VTK_DIR might require manual
            configuration
         -- GDCM_WRAP_PYTHON
         -- GDCM_VTK When this option is on VTK_DIR might require manual
            configuration
         -- GDCM_WRAP_PYTHON

+        -- CMAKE_CXX_FLAGS (when working with gcc of course) should be set to
+           -g -O0 -Wall -W -Wshadow -Wunused-variable -Wunused-parameter
+           -Wunused-function -Wunused -Wno-system-headers -Wno-deprecated
+           -Woverloaded-virtual
+           (this is to avoid spurious problems with overloading)

       * Configure cmake: hit c
       * Generate the makefiles (or dsw): hit g
   - Compile gdcm
       * Configure cmake: hit c
       * Generate the makefiles (or dsw): hit g
   - Compile gdcm


@@ -128,7 +133,7 @@ gdcm coding style and religious/agnostic beliefs (proposition)
    across multiple lines as necessary. 
  - Methods and functions should keep a reasonable number of lines when
    possible (a typical editor displays 50 lines). Avoid code duplication.
    across multiple lines as necessary. 
  - Methods and functions should keep a reasonable number of lines when
    possible (a typical editor displays 50 lines). Avoid code duplication.

-   Allways prefer creating a new method or function to duplication.
+   Always prefer creating a new method or function to duplication.

    A high indentation level generally suggests the need for a new
    method or function.
  - All the code should be properly indented. The appropriate indentation
    A high indentation level generally suggests the need for a new
    method or function.
  - All the code should be properly indented. The appropriate indentation


@@ -151,7 +156,7 @@ gdcm coding style and religious/agnostic beliefs (proposition)
     uppercase as in LUT or RGBA.]
    While this does result in long names, it self-documents the code.
  - Naming Files:
     uppercase as in LUT or RGBA.]
    While this does result in long names, it self-documents the code.
  - Naming Files:

-   Files should have the same name as the class, with an "gdcm" prepended.
+   Files should have the same name as the class, with a "gdcm" prepended.

    Header files are named .h, while implementation files are named either
    .cxx or .txx, depending on whether they are implementations of templated
    classes. For example, the class gdcm::Document is declared and defined
    Header files are named .h, while implementation files are named either
    .cxx or .txx, depending on whether they are implementations of templated
    classes. For example, the class gdcm::Document is declared and defined


@@ -163,7 +168,7 @@ gdcm coding style and religious/agnostic beliefs (proposition)
    named beginning with a capital letter, as in GetImageDataSize().
  - Naming Local Variables:
    Local variables begin in lowercase. There is more flexibility in the
    named beginning with a capital letter, as in GetImageDataSize().
  - Naming Local Variables:
    Local variables begin in lowercase. There is more flexibility in the

-   naming of local variables allthough they still should convey some
+   naming of local variables although they still should convey some

    semantics.
 
 * Classes:
    semantics.
 
 * Classes:


@@ -338,17 +343,28 @@ gdcm coding style and religious/agnostic beliefs (proposition)
       T* foo = 0;
    and not 
       T *foo = 0;
       T* foo = 0;
    and not 
       T *foo = 0;

- - Allways define a typedef for a new type and be consistent in usage.
+ - Always define a typedef for a new type and be consistent in usage.

    Use
       typedef Header* HeaderPointer;
       HeaderPointer MyHeaderPointer;
  - One notorious counter example for non using C style inclusion concerns
    Use
       typedef Header* HeaderPointer;
       HeaderPointer MyHeaderPointer;
  - One notorious counter example for non using C style inclusion concerns

-   exact-width intergers (since there seem to be no equivalent for C++).
+   exact-width integers (since there seem to be no equivalent for C++).

    When using exact-width integers use the typedef names defined by
    the Basic ISO C99: 7.18 Integer types i.e.
       int8_t     int16_t     int32_t     int64_t (signed integers)
    and
       uint8_t    uint16_t    uint32_t    uint64_t (unsigned integers).
    When using exact-width integers use the typedef names defined by
    the Basic ISO C99: 7.18 Integer types i.e.
       int8_t     int16_t     int32_t     int64_t (signed integers)
    and
       uint8_t    uint16_t    uint32_t    uint64_t (unsigned integers).

+   Conversion table is then:
+    unsigned char       -> uint8_t;
+    unsigned short      -> uint16_t;
+    unsigned int        -> uint32_t;
+    unsigned long       -> uint32_t;
+    unsigned long long  -> uint64_t;
+    (signed) char       -> int8_t; 
+    short               -> int16_t; 
+    int                 -> int32_t; 
+    long                -> int32_t; 
+    long long           -> int64_t;

    Hence do not use declarations like "unsigned int".
    With g++, accessing those typedef is achieved by the following
       #include <stdint.h>
    Hence do not use declarations like "unsigned int".
    With g++, accessing those typedef is achieved by the following
       #include <stdint.h>


@@ -357,9 +373,13 @@ CVS policy
 * All the commits should be atomic. They must preserve the compilation
   in order to prevent checkouts with broken code.
 * All the commits must correspond to a stade of the code where ctest
 * All the commits should be atomic. They must preserve the compilation
   in order to prevent checkouts with broken code.
 * All the commits must correspond to a stade of the code where ctest

-  runs and has no failing subtest. Allways run ctest before commiting.
-  Note: * you can launch ctest in verbose mode through the command
+  runs and has no failing subtest. Always run ctest before commiting.
+  Note: * you can start ctest in verbose mode through the command

              ctest -V >& log
              ctest -V >& log

-        * you can launch a single test through ctest with
+        * you can start a single test through ctest with

              ctest -R FailingTestName -V >& log
 ------------------------------------------------
              ctest -R FailingTestName -V >& log
 ------------------------------------------------

+Compiler flags policy:
+ When working with gcc please use the flags specified in DEVELOPPER file
+ (in order to avoid difficult overloading problems).
+------------------------------------------------