Skip to content

Instantly share code, notes, and snippets.

@thomasjwebb
Last active July 11, 2016 00:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save thomasjwebb/cca52dbde6658bc7cecf24eb26a102ee to your computer and use it in GitHub Desktop.
Save thomasjwebb/cca52dbde6658bc7cecf24eb26a102ee to your computer and use it in GitHub Desktop.

Coding Style for C++

Just reminders mostly for myself and only for C++ (not C, not C#, not javascript, just C++). Work in progress.

The first rule is if you're mostly based on a third-party lib, using their build tools, mostly using their objects, especially if you're using their stuff to generate code, then use their style and forget these rules (except where there is ambiguity). If you really hate their style then don't and make auto-translaters, wrappers, etc. The important thing is to be consistent within the project and with respect to the industry at hand (except when the industry has godawful norms that need to be changed).

Brackets

Attached brackets for flow (but else on new line, not same line as previous bracket), brackets on their own line for class and functions.

// ok
if (condition) {
    break;
}

// ok
if (condition) break;

// NO
if (condition)
    break;

// NO
class Blob {
    ...    
};

// ok
class Blob
{
    ...    
};

// ok
int flobbulate()
{
    ...
}

// NO
int flobbulate() {
    ...
}

Naming

class names struct names are CamelCase. function names are backCamel. if you do IBM style and make functions CamelCase, you are an abomination.

Variables are also backCamel, though I briefly did K&R style (snake_case) when I was trying to make my C++ look like ruby so there's a lot of variables that style too left over that need to be changed.

Attach & and * to variable name, not to type:

int *p; // ok
int* p; // not ok
int * p; // no longer okay, but was my old style so there may be some of this left around.. change it!

No Hungarian notation. Use _ as prefix in input variables if need be. Don't prefix interface classes with I if you can make it a name that describes a property a class implementing it would have (i.e., Streamable, Seekable). I use this rule in languages that have the I** convention and proper interface support too like haxe and C#.

Use descriptive variable names, not abbreviations. Use final _ to denote question mark. Statements should look as sentence-like as possible with C++ (not very, but easy to see what's going on). This makes commenting less of a chore.

If you can avoid it, don't embed the type of the object in the variable name (i.e., _s or _string suffixes for strings) unless it's the only non-atrocious way to avoid name clashes (Which happens with gui stuff, e.g., labels vs. editors). But DO include units if applicable (i.e., timeInMs).

Prefer English variables. Or at least keep all the variables, class names, etc. in a given project or module in the same language and try to make statements read like a sentence in that language.

Definitions and Implementations

Avoid defining functions inline in the class definitions. Keep implementations in the C++ files in the same order as they appear in the definitions.

Comment well, but also make your code self-commenting.

Header files, .h c++ files, .cc, c files .c.

Break any of these rules if the alternative is atrocious or inelegant code. Sometimes, especially with C++, something that doesn't read like a sentence is the most elegant way to express it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment