WebKit Coding Style Guidelines

Sep 13, 2005

by Maciej Stachowiak

Indenting

Use spaces to indent. Tabs should not appear in code files (with the exception of files that require them e.g. Makefiles).
The indent size is 4 spaces.
Code editors should be configured to expand tabs that you type to 4 spaces.

Braces

Function definitions – open and close braces should be on lines by themselves. Do not put the open brace on the same line as the function signature. For example:

Right:
```
void foo()
{
    // do stuff
}
```
Wrong:
```
void foo() {
    // do stuff
}
```
Loop control structures, including for, while and do statements – the open brace should go on the same line as the as the control structure.

Right:
```
for (int i = 0; i < 10; i++) {
    // do stuff
}
```
Wrong:
```
for (int i = 0; i < 10; i++) 
{
    // do stuff
}
```

If/else statements - as above, but if there is an else clause, the close brace should go on the same line as the else. Also, one-line if or else clauses should not get braces.

Right:

if (timeToGetCoffee) {
    buyCoffee(&coffee);
    chugIt(coffee);
} else if (timeToGoHome)
    // comment on else case
    outtaHere = true;

Wrong:

if (timeToGetCoffee)
{
    buyCoffee(&coffee);
    chugIt(coffee);
// comment on else case
} else if (timeToGoHome) 
{
    outtaHere = true;
}
        
if (timeToGetCoffee) {
} 
else

// comment on else case

if (timeToGoHome) 
    outtaHere = true;

Parentheses

Function declarations and calls – do not use any spaces between the name and the open paren, inside the parentheses, or before commas that separate arguments. Do use a single space after commas that separate arguments.

Right:

int myFunction(int arg1, float arg2);

void noArgFunction(); // for C++ or Objective-C++

void noArgFunction(void); // for C or Objective-C

Wrong:

int myFunction (int arg1, float arg2);

int myFunction( int arg1 , float arg2 );

void noArgFunction ();

Control structures, such as if, while, do and switch – use a single space before the open paren, but no spaces inside the parentheses.

Null, false and 0

In C++, the null pointer value should be written as 0. In C it should be written as NULL. In Objective-C, it should be written as nil if it is being used as a null pointer of type id or another ObjC object type, otherwise NULL.
True and false values of type bool (common in C and C++), or just generic true/false values, should be written as true and false. Values of the Objective-C BOOL type should be written as YES and NO.

Tests for null pointers, false values and 0 values should all be done diretly, not through an inqueality or equality comparison.

Right:


// test for true
if (foo->isSomething()) {
    // code
}

// test for false
if (!foo->isSomething()) {
    // code
}

// test for non-null
if (ptr) {
   // code
}

// test for null
if (!ptr) {
   // code
}

// test for nonzero
if (count) {
    // code
}

// test for zero
if (!count) {
    // code
}

Wrong:

if (foo->isSomething() == true) {
    // code
}

if (foo->isSomething() != false) {
    // code
}

if (p == NULL) {
    // code
}

if (nil != p) {
    // code
}

if (count == 0) {
    // code
}

Names

General Rule: With very few exceptions, prefer embedded capitals instead of underscores for class, function and variable names.
C++ and Objective-C classes, interfaces and protocols, and other type names – these names should start with a capital letter and use InterCaps.

Right:
```
class MyImportantClass;
```
Wrong:
```
class My_important_class;

class myImportantClass;
```
Local variables should use interCaps, but the first word should start with a lowercase letter, like this:

Right:
```
int myInt;
```
Wrong:
```
int MyInt;

int my_int;
```
Free function names in C++ should follow the same naming conventions as local variables. Most functions should be named to sound like verb phrases, like “openDoor” or “walkAroundTheBlock”. (getters, setters, predicates?)
C++ data members should be named like local variables, but with a prefix of m_.
C++ member functions should follow the same naming convention as free functions.
Objective-C methods should follow the usual Cocoa naming style – they should read like a phrase or sentence and each piece of the selector should start with a lowercase letter and use intercaps.
Objective-C instance variables should be named like local variables but starting with an underscore.
Pointer and reference types – pointer types should be written with a space between the type name and the * (so the * is adjacent to the following identifier if any). For reference types, the & goes next to the type name.
Enum members should user InterCaps with an initial capital letter.
#defined constants should use all uppercase names with words separated by underscores.
Macros that expand to function calls or other non-constant computation: these should be named like functions, and should have parentheses at the end, even if they take no arguments (with the exception of some special macros like ASSERT). Note that usually it is preferrable to use an inline function in such cases instead of a macro.

Right:
```
#define WBStopButtonTitle()  NSLocalizedString(@"Stop", @"Go/Stop button title")
```
Wrong:
```
#define WB_STOP_BUTTON_TITLE  NSLocalizedString(@"Stop", @"Go/Stop button")

#define WBStopButtontitle  NSLocalizedString(@"Stop", @"Go/Stop button")
```
Acronyms in names: If an identifier includes an acronym, make the acronym all-uppercase or all-lowercase, depending on whether a word in that position would be capitalized or not.

Right:
```
urlVariable
myURLAccessor:
```
Wrong:
```
uRLVariable
myUrlAccessor:
```