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.
I prefer to use 4 spaces instead of tabs. There are a couple reasons for this:
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.
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.
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 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.
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.
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.
In the following contexts, braces go on their own line:
In the following contexts, braces go inline:
enum
and C struct
definitionsLabels go at the same level of indentation as their parent block (not its contents). By “labels” I include all of the following:
goto
jumpscase
labels in switch
statementspublic
, private
, and protected
labels in C++ classesFor 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
}
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; }