oF code style

The openFrameworks code style, modeled after the Qt style

See bottom for proposed changes and all modifications to the original Qt style.

Indentation

• 4 spaces are used for indentation
• Spaces, not tabs!

Declaring variables

• Declare each variable on a separate line

• Avoid short (e.g. a, rbarr, nughdeget) names whenever possible

• Single character variable names are only okay for counters and temporaries, where the purpose of the variable is obvious

• Wait when declaring a variable until it is needed

     // Wrong
    int a, b;
    char *c, *d;
     // Correct
    int height;
    int width;
    char *nameOfThis;
    char *nameOfThat;
  

• Variables and functions start with a lower-case letter. Each consecutive word in a variable’s name starts with an upper-case letter

• Avoid abbreviations

     // Wrong
    short Cntr;
    char ITEM_DELIM = '\t';
     // Correct
    short counter;
    char itemDelimiter = '\t';
  

• Classes always start with an upper-case letter.

Whitespace

• Use blank lines to group statements together where suited

• Always use only one blank line

• Always use a single space after a keyword and before a curly brace.

     // Wrong
    if(foo){
    }
     // Correct
    if (foo) {
    }
  

• For pointers or references, always use a single space between the type and * or &, but no space between the * or & and the variable name.

    char *x;
    const QString &myString;
    const char * const y = "hello";
  

• Surround binary operators with spaces.

• No space after a cast.

• Avoid C-style casts when possible.

     // Wrong
    char* blockOfMemory = (char* ) malloc(data.size()); 
     // Correct
    char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()));
  

Braces

• As a base rule, the left curly brace goes on the same line as the start of the statement:

     // Wrong
    if (codec)
    {
    } 
     // Correct
    if (codec) {
    }
  

• Exception: Function implementations and class declarations always have the left brace on the start of a line:

    static void foo(int g)
    {
    	qDebug("foo: %i", g);
    }
     //
    class Moo
    {
    };
  

• Use curly braces when the body of a conditional statement contains more than one line, and also if a single line statement is somewhat complex.

     // Wrong
    if (address.isEmpty()) {
    	return false;
    }
     // 
    for (int i = 0; i < 10; ++i) {
    	qDebug("%i", i);
    }
     // Correct
    if (address.isEmpty())
    	return false;
     // 
    for (int i = 0; i < 10; ++i)
    	qDebug("%i", i);
  

• Exception 1: Use braces also if the parent statement covers several lines/wraps

     // Correct
    if (address.isEmpty() || !isValid()
    	|| !codec) {
    	return false;
    }
  

• Exception 2: Use braces also in if-then-else blocks where either the if-code or the else-code covers several lines

     // Wrong
    if (address.isEmpty())
    	return false;
    else {
    	qDebug("%s", qPrintable(address));
    	++it;
    }
     // Correct
    if (address.isEmpty()) {
    	return false;
    } else {
    	qDebug("%s", qPrintable(address));
    	++it;
    } 
     // Wrong
    if (a)
    	if (b)
    	    ...
    	else
    	    ...
     // Correct
    if (a) {
    	if (b)
    	    ...
    	else
    	    ...
    }
  

• Use curly braces when the body of a conditional statement is empty

     // Wrong
    while (a); 
     // Correct
    while (a) {}
  

Parentheses

• Use parentheses to group expressions:

     // Wrong
    if (a && b || c) 
     // Correct
    if ((a && b) || c)
     // Wrong
    a + b & c
     // Correct
    (a + b) & c
  

Switch statements

• The case labels are in the same column as the switch

• Every case must have a break (or return) statement at the end or a comment to indicate that there’s intentionally no break, unless another case follows immediately.

    switch (myEnum) {
    case Value1:
    	doSomething();
    	break;
    case Value2:
    case Value3:
    	doSomethingElse();
    	// fall through
    default:
    	defaultHandling();
    	break;
    }
  

Line breaks

• Keep lines shorter than 100 characters; insert breaks if necessary.

• Commas go at the end of a broken line; operators start at the beginning of the new line. An operator at the end of the line is easy to not see if your editor is too narrow.

     // Correct
    if (longExpression
    	+ otherLongExpression
    	+ otherOtherLongExpression) {
    }
     // Wrong
    if (longExpression +
    	otherLongExpression +
    	otherOtherLongExpression) {
    }
  

Inheritance and the virtual keyword

• When reimplementing a virtual method, do not put the virtual keyword in the header file.

General exception

• Feel free to break a rule if it makes your code look bad.

Proposed changes

From the forum thread:

• Break lines at 80, not 100 chars to ease side-by-side display (and work with IDEs with lots of stuff on the sides). Two 80-char text files just work out on my [bb] laptop. Maybe we drop the requirement if it messes up too much existing code.
• Opening braces for functions and classes on the same line, also?
• Operators on wrapping lines at the end of the previous line. (just jrocha's taste, though, he says)
• Guidelines for commenting/doxygen are needed! (Better do that later, and in a separate process)
• Define a good comment: No redundancy; clearer code is better than comments to explain; if code is changed, keep the comments up-to-date; comment on the "why", not the "what".

From the PiratePad:

• use ofLog(), printf and cout should never be used in the core.
• header files should be organized in order of usage: most commonly used first
• const should be used in new code, but not added to old code
• we don't add unnecessary spaces
• loops and conditionals always deserve braces, even single line ones
• implementations are preceeded by 2 slashes and 40 dashes
• usage of an enum type is preferred over int when passing enums. even better if the enum is the member of a class.

Hot items for debate:

• variable and comment alignment
• usage of initialization lists

All modifications to the Qt style

(Let's keep those as few as possible)

• Removed "Q" class-name prefix, as it makes no sense for oF.