Faith Ekstrand

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:

• Class definitions
• Function definitions
• Control-flow statements where the line wraps (putting the brace on its own line helps set the control flow statement out from the following block)

In the following contexts, braces go inline:

• enum and C struct definitions
• Control-flow statements that do not wrap, 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:

• Labels for goto jumps
• case labels in switch statements
• public, private, and protected labels in C++ classes

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

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:

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:

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:

int get_property() const { return property; }