1. Language Standards

2. Naming Conventions

2.1. General notes

Use short names where it makes sense, for example counters (i,
j, k etc).

2.2. Class Names

Name the class after what it is.

Use compound names with up to three words.

Use nouns.

CamelCase: Use upper case letters as word separators, lower case for
the rest of a word

First character in a name is upper case

No underscores ('_')

Examples
: class BoundaryGeometry;

2.3. File Names

Use one file per class definition.

The file name is the same as the class name.

Example
: BoundaryGeometry.cpp\
BoundaryGeometry.h

2.4. Class Library Names

Use name spaces - so you don't have the problem

When not using name spaces, it's common to prevent class name
clashes by prefixing class names with a short unique string.

Examples
: class QObject; // the base class of all Qt objects

2.5. Method Names

Use camelCase (first character is lower case).

No underscores ('_')

Use a verb as first part in a compound name

isInGeometry - to ask a question about something.

getMaxCoords - to get a value

setFoo - to set a value

...

Example
: getMaxExtend();

2.6. C Function Names

All lower case with underscore as separators.

Example
: get_max_extend();

2.7. Class Member Variable Names

Use descriptive names.

Use camelCase_m: like method names but append _m.

No other underscores

Example
: bool doHdf5Save_m;

2.8. Method Argument and local Variable Names

Use descriptive names.

camelCase

2.9. Pointer and Reference Variables Names

You may append _r to reference variable names.

Same for pointer variable names with _p.

2.10. Global and Static Variables

Use global and static variables only if really required.

You should append _g to global variable names to make the scope
clear.

Same for static variable names with _s.

If you have multiple suffixe use _mp, _gp etc.

2.11. Global Constants, Enums and Macro Names

All caps with underscore as separators.

Consts and Enums without class scoping should have a reasonable
prefix to avoid conflicts.

Example
: enum {STATE_ERR, STATE_OPEN, STATE_RUNNING, STATE_DYING};

2.12. Type Names

Make a typedef for types based on native types.

Use the _t suffix for typedefs: typedef UniformMesh Mesh_t

Example:

#if defined(USE_LARGE_INDICES)typedefint64_th5_loc_idx_t;// type for a local indextypedefint64_th5_loc_id_t;// type for a local ID#elsetypedefint32_th5_loc_idx_t;// type for a local indextypedefint32_th5_loc_id_t;// type for a local ID#endif

Comments are good, but there is also a danger of over-commenting. NEVERtry to explain HOW your code works in a comment: it's much better towrite the code so that the _working_ is obvious, and it's a waste oftime to explain badly written code.Generally, you want your comments to tell WHAT your code does, not HOW.Also, try to avoid putting comments inside a function body: if thefunction is so complex that you need to separately comment parts of it,you should probably go back to chapter 6 for a while. You can makesmall comments to note or warn about something particularly clever (orugly), but try to avoid excess. Instead, put the comments at the headof the function, telling people what it does, and possibly WHY it doesit.

4. Methods and Functions

4.1. Complexity

Do *one* thing per method.

Break down complex methods.

Use helper functions/methods.

3-4 levels of indentation are OK - 6+ definitely not.

Quote from the Linux coding style:

Functions should be short and sweet, and do just one thing. They shouldfit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,as we all know), and do one thing and do that well.The maximum length of a function is inversely proportional to thecomplexity and indentation level of that function. So, if you have aconceptually simple function that is just one long (but simple)case-statement, where you have to do lots of small things for a lot ofdifferent cases, it's OK to have a longer function.However, if you have a complex function, and you suspect that aless-than-gifted first-year high-school student might not evenunderstand what the function is all about, you should adhere to themaximum limits all the more closely. Use helper functions withdescriptive names (you can ask the compiler to in-line them if you thinkit's performance-critical, and it will probably do a better job of itthan you would have done).Another measure of the function is the number of local variables. Theyshouldn't exceed 5-10, or you're doing something wrong. Re-think thefunction, and split it into smaller pieces. A human brain cangenerally easily keep track of about 7 different things, anything moreand it gets confused. You know you're brilliant, but maybe you'd liketo understand what you did 2 weeks from now.

4.2. Centralized exiting and early returns

If a function exists from multiple location and some common work has
to be done (like cleanup), the goto statement becomes handy.

If there is no common work to be done, return from a function as
soon as possible.

Rationale:

unconditional statements are easier to understand and follow

nesting is reduced

errors by not updating individual exit points when making
modifications are prevented

5. Formatting

5.1. Indentation

Quote from Linux Kernel coding style:

Tabs are 8 characters, and thus indentations are also 8 characters.There are heretic movements that try to make indentations 4 (or even 2!)characters deep, and that is akin to trying to define the value of PI tobe 3.

We are heretic and use 4 characters (but 8 character are also
accepted).

Use spaces not tabs.

Don't even think about redefining the TAB-character ...

Another quote from the Linux Kernel coding style:

Rationale: The whole idea behind indentation is to clearly define wherea block of control starts and ends. Especially when you've been lookingat your screen for 20 straight hours, you'll find it a lot easier to seehow the indentation works if you have large indentations.Now, some people will claim that having 8-character indentations makesthe code move too far to the right, and makes it hard to read on a80-character terminal screen. The answer to that is that if you needmore than 3 levels of indentation, you're screwed anyway, and should fixyour program.In short, 8-char indents make things easier to read, and have the addedbenefit of warning you when you're nesting your functions too deep.Heed that warning.

5.2. Breaking long lines and strings

Avoid long lines.

If a line is longer than 80 characters, think about breaking it into reasonable chunks.

This applies also to strings.

Without defining a hard limit, line with more than 160 characters are definitely far too long.

Comments should fit within 80 characters per line

5.3. Placing Spaces

use a space before an opening parenthesis ( and opening curly
bracket {.

do not use a space before an opening square bracket.

use spaces around binary operators

but no space after unary operators

no space after prefix increment- and decrement operator

no space before postfix increment- and decrement operator

no space around . and ->

Examples:

if (i == 42) return i;

i = j + 2;

i += 42;

i++;

mesh->fname = argv[1];

5.4. Pointer and Reference Variables

If you define a pointer or reference type, place * resp. & close
to the type not the variable name.

5.7 Tools

UniversalIndentGUI offers a live preview for setting the parameters of nearly any indenter. You change the value of a parameter and directly see how your reformatted code will look like. Save your beauty looking code or create an anywhere usable batch/shell script to reformat whole directories or just one file even out of the editor of your choice that supports external tool calls"

6. Memory Allocation

Use std::vector for dynamic arrays

Use std::unique_ptr/std::shared_ptr where ever possible.

7. Error Handling

Always check error conditions and handle them!

If we can proceed, it may be enough to print a warning.

Otherwise print an error message and return with an error code. Do
not proceed!