* 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
* 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 parantheses, or braces. Use
- if ( someLocalVariable == 2 ) { ClassMenber += 1; }
+ - Add spaces around parentheses, or braces. Use
+ 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 );
* \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 element Element 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.
*/
- std::string Document::GetEntryByNumber(guint16 group, guint16 element)
+ std::string Document::GetEntryByNumber(guint16 group, guint16 elem)
{
...
}
warnings won't work).
- Don't use the C standard library. Don't include stdio.h, ctype.h...
Don't use printf(), sprinf(), FILE*...
- - Don't use the NULL notation (either as macro, or as const int NULL=0).
+ - Don't use the NULL notation (neither as macro, nor as const int NULL=0).
A pointer that doesn't refer to an object should simply be defined as
DataPointer* MyDataPointer = 0;
* Basic types:
- Assume T is a given type. When declaring or defining with the
"pointer to T" notation, the * character must be adjacent to
- the type and not the variable. That is use
+ the variable and not the type. That is use
+ 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 :
+ T &foo = 0;
and not
- T *foo = 0;
+ T& foo = 0;
+
+ (Doxygen will not have any longer to correct)
+
- Always define a typedef for a new type and be consistent in usage.
Use
- typedef Header* HeaderPointer;
+ 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++).
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff