X-Git-Url: https://git.creatis.insa-lyon.fr/pubgit/?a=blobdiff_plain;f=DEVELOPPER;h=fd8a67964977e52c0eae3955c520a58f77b13ed1;hb=f163238b46fdd5a54c1b6b70549ab9466c101d14;hp=3f01c29ec3bcf2148c890f6e42edba9ad36d1156;hpb=d71e2e62b38383d9b960760f6d81c4d545d59fba;p=gdcm.git diff --git a/DEVELOPPER b/DEVELOPPER index 3f01c29e..fd8a6796 100644 --- a/DEVELOPPER +++ b/DEVELOPPER @@ -128,7 +128,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. - 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 @@ -151,7 +151,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: - 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 @@ -163,7 +163,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 - naming of local variables allthough they still should convey some + naming of local variables although they still should convey some semantics. * Classes: @@ -338,17 +338,28 @@ gdcm coding style and religious/agnostic beliefs (proposition) 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 - 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). + 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 @@ -357,9 +368,9 @@ 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 - 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 - * you can launch a single test through ctest with + * you can start a single test through ctest with ctest -R FailingTestName -V >& log ------------------------------------------------