Coding Style

This doesn’t really count as a project but it may be a useful reference for other people who may want to work on one of my projects.

The following is an attempt to document my personal coding style in several languages. While I try and be somewhat consistent across languages, ther are necessarily differences. I will attempt to point out those differences as I go.

Tabs/Spaces

I prefer to use 4 spaces instead of tabs. There are a couple reasons for this:

  1. I find an 8-space tab-stop to be annoying large.
  2. If I just change the tab-stop in vim to 4 spaces, then the code will look different in different places. Specifically, it breaks the way line-wrapping is done.

Line wrapping

This one is a little more loose. In general, I wrap lines to 80 characters. Whenever a line is wrapped, the extra lines are all double-indented (8 spaces) to differentiate them from the next statement.

I also try to make the line breaks as “nice” as possible in the sense that I try to have as few broken expressions as I can. I would rather have one expression be broken in three places than have all of the sub-expressions broken. For example, if I have a function call that has complicated expressions in several of the arguments, then I may put one argument per line to avoid breaking any of the arguments across lines.

Naming conventions

Constants

For constants, I use ALL_UPPER_CASE. It doesn’t matter whether the constant is a public static constant variable, a #define, or an enum.

Classes and structures

For C++, Python, and Java class names, I use UpperCamelCase.

For C structures, I usually use words_with_underscores. I will also sometimes use words_with_underscores in C++ if the class/structure is one with few member functions and predominately public fields.

Variable and function names

Variable and function names depend on the language and the project. In Java, I usually use lowerCamelCase. In C and C++, I usually words_with_underscores. However, this can change from one project to another. For example, Qt uses lowerCamelCase for function names, so if I am working on a primarily Qt project, I am liable to follow this convention.

Member variables

I do not use a special prefix for member variables. I find the mMyMemberVar extremely annoying. However, in C++ projects where I am using words_with_underscores notation for variables, I will frequently prefix private member variables with an underscore.

Indentation

Every block is indented one level further than its containing block. The one exception to this rule is that I don’t always indent the contents of C++ namespaces or extern "C". This is because these usually contain the entire contents of the file and so indenting just adds unneeded whitespace. However, if I am declaring a namespace as a very small part of a file, its contents will be indented.

Braces

In the following contexts, braces go on their own line:

In the following contexts, braces go inline:

Labels

Labels go at the same level of indentation as their parent block (not its contents). By “labels” I include all of the following:

For example, the labels in a switch statement look like this:

#!c
switch(num) {
case 1:
case 2:
    printf("1 or 2\n");
    break;
default:
    // Do other stuff
}

Function declarations

For function definitions, I put the return type and other quantifiers on their own line, then the name and arguments, then the open brace on its own line. For example:

#!c
int
main(int argc, char **argv)
{
    printf("Hello World!\n");
}

For function prototypes (with no function body), I place everything inline. The exception here is that if the return type is long, I may put the return type and other qualifiers on their own line to avoid a line break in the argument list. For example:

#!c
int main(int argc, char **argv);

When writing inline functions in C++, I may place the entire function on one line if the function is extremely short. For instance, a simple getter may look like this:

#!cpp
int get_property() const { return property; }