coding style

1.
Use spaces, not tabs. Tabs should only appear in files that require them for semantic meaning, like Makefiles.

2.
A case label should line up with its switch statement. The case statement is indented.
Right:
switch (condition) {
case fooCondition:
case barCondition:
i++;
break;
default:
i--;
}
Wrong:switch (condition) {
case fooCondition:
case barCondition:
i++;
break;
default:
i--;
}

3.
Boolean expressions at the same nesting level that span multiple lines should have their operators on the left side of the line instead of the right side.
Right:
return attr->name() == srcAttr
attr->name() == lowsrcAttr
(attr->name() == usemapAttr && attr->value().domString()[0] != '#');
Wrong:
return attr->name() == srcAttr
attr->name() == lowsrcAttr
(attr->name() == usemapAttr && attr->value().domString()[0] != '#');

4.
Do not place spaces around unary operators.
Right:
i++;
Wrong:
i ++;

5.
Do place spaces around binary and ternary operators.
Right:
y = m * x + b;
f(a, b);
c = a b;
return condition ? 1 : 0;
Wrong:
y=m*x+b;
f(a,b);
c = ab;
return condition ? 1:0;

6.
An else statement should go on the same line as a preceding close brace.
Right:
if (condition) {
...
} else {
...
}
Wrong:
if (condition) {
...
}
else {
...

7.
Function definitions: place each brace on its own line.
Right:
int main()
{
...
}
Wrong:
int main() {
...
}

8.
Control clauses without a body should use empty braces:
Right:
for ( ; current; current = current->next) { }
Wrong:
for ( ; current; current = current->next);

9.
Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.
Right:
if (condition)
doIt();
if (!ptr)
return;
if (!count)
return;
Wrong:
if (condition == true)
doIt();
if (ptr == NULL)
return;
if (count == 0)
return;

10.
Use CamelCase. Capitalize the first letter, including all letters in an acronym, in a class, struct, protocol, or namespace name. Lower-case the first letter, including all letters in an acronym, in a variable or function name.
Right:
struct Data;
size_t bufferSize;
class HTMLDocument;
String mimeType();
Wrong:
struct data;
size_t buffer_size;
class HtmlDocument;
String MIMEType();

11.
Use full words, except in the rare case where an abbreviation would be more canonical and easier to understand.
Right:
size_t characterSize;
size_t length;
short tabIndex; // more canonical
Wrong:
size_t charSize;
size_t len;
short tabulationIndex; // bizarre

12.
Prefix C++ data members with "m_".
Right:
class String {
...
short m_length;
};
Wrong:
class String {
...
short length;
};

13.
Precede boolean values with words like "is" and "did".
Right:
bool isValid;
bool didSendData;
Wrong:
bool valid;
bool sentData;

14.
Use descriptive verbs in function names.
Right:
bool convertToASCII(short*, size_t);
Wrong:
bool toASCII(short*, size_t);

15.
#define, #ifdef "header guards" should be named exactly the same as the file (including case), replacing the '.' with a '_'.
Right:
// HTMLDocument.h
#ifndef HTMLDocument_h
#define HTMLDocument_h
Wrong:
// HTMLDocument.h
#ifndef _HTML_DOCUMENT_H_
#define _HTML_DOCUMENT_H_

16.
Constructors for C++ classes should initialize all of their members using C++ initializer syntax. Each member (and superclass) should be indented on a separate line, with the colon or comma preceding the member on that line.
Right:
MyClass::MyClass(Document* doc)
: MySuperClass()
, m_myMember(0)
, m_doc(doc)
{
}
MyOtherClass::MyOtherClass()
: MySuperClass()
{
}
Wrong:
MyClass::MyClass(Document* doc) : MySuperClass()
{
m_myMember = 0;
m_doc = doc;
}
MyOtherClass::MyOtherClass() : MySuperClass() {}

參考至：http://webkit.org/coding/coding-style.html
感謝dlackty提供!!

連結：http://ms.ntcb.edu.tw/~s9256041/coding%20style.doc