Context Navigation

← Previous Change
Wiki History
Next Change →

Changes between Version 10 and Version 11 of Coding Style Guidelines

Timestamp:: Jan 10, 2012 1:09:19 PM (12 years ago)
Author:: girard@chromium.org
Comment:: Two copies of the standards exist. Removing this one, and sending readers to the correct one.

Legend:

: Unmodified
: Added
: Removed
: Modified

Coding Style Guidelines

-                      v10
+                      v11
+[[PageOutline]]
+== Indenting ==
+ * Use spaces to indent. Tabs should not appear in code files (with the exception of files that require tabs, e.g. Makefiles). We have a Subversion pre-commit script that enforces this rule for most source files, preventing commits of files that don't follow this rule.
+ * 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.
+ '''Right:'''
+ {{{
+ #!cpp
+void foo()
+{
+    // do stuff
+}
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+void foo() {
+    // do stuff
+}
+ }}}
+ * Other braces including `for`, `while`, `do`, `switch` statements, as well as `class`, `struct` and `namespace` definitions — the open brace should go on the same line as the as the control structure. One-line for/while/do loops should not get braces.
+ '''Right:'''
+ {{{
+ #!cpp
+for (int i = 0; i < 10; i++) {
+    // do stuff
+}
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+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:'''
+ {{{
+ #!cpp
+if (timeToGetCoffee) {
+    buyCoffee(&coffee);
+    chugIt(coffee);
+} else if (timeToGoHome)
+    // comment on else case
+    outtaHere = true;
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+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:'''
+ {{{
+ #!cpp
+int myFunction(int arg1, float arg2);
+void noArgFunction(); // for C++ or Objective-C++
+void noArgFunction(void); // for C or Objective-C
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+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 Objective-C object type, otherwise `NULL`.
+ * True and false values of type `bool` (common in C and C++), or 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 directly, not through a comparison.
+ '''Right:'''
+ {{{
+ #!cpp
+// 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:'''
+ {{{
+ #!cpp
+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:'''
+ {{{
+ #!cpp
+class MyImportantClass;
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+class My_important_class;
+class myImportantClass;
+ }}}
+ * Local variables should use interCaps, but the first word should start with a lowercase letter, like this:
+ '''Right:'''
+ {{{
+ #!cpp
+int myInt;
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+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.
+ * Enum members should user !InterCaps with an initial capital letter.
+ * `#define`d 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:'''
+ {{{
+ #!cpp
+#define WBStopButtonTitle() \
+        NSLocalizedString(@"Stop", @"Stop button title")
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+#define WB_STOP_BUTTON_TITLE \
+        NSLocalizedString(@"Stop", @"Stop button title")
+#define WBStopButtontitle \
+        NSLocalizedString(@"Stop", @"Stop button title")
+ }}}
+ * 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:'''
+ {{{
+ #!cpp
+urlVariable
+myURLAccessor:
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+uRLVariable
+myUrlAccessor:
+ }}}
+== Other Punctuation ==
+ * Constructors for C++ classes should initialize all of their members using C++ constructor syntax. Each member (and superclass) should be indented on a separate line, with the colon or comma preceding the member on that line.
+ '''Right:'''
+ {{{
+ #!cpp
+MyClass::MyClass(Document* doc)
+    : MySuperClass()
+    , m_myMember(0)
+    , m_doc(doc)
+{
+}
+MyOtherClass::MyOtherClass()
+    : MySuperClass()
+{
+}
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+MyClass::MyClass(Document* doc) : MySuperClass()
+{
+    m_myMember = 0;
+    m_doc = doc;
+}
+MyOtherClass::MyOtherClass() : MySuperClass() {}
+ }}}
+ * Pointer types in non-C++ code — Pointer types should be written with a space between the type and the `*` (so the `*` is adjacent to the following identifier if any).
+ * Pointer and reference types in C++ code — Both pointer types and reference types should be written with no space between the type name and the `*` or `&`.
+ '''Right:'''
+ {{{
+ #!cpp
+Image* SVGStyledElement::doSomething(PaintInfo& paintInfo)
+{
+  SVGStyledElement* element = static_cast<SVGStyledElement*>(node());
+  const KCDashArray& dashes = dashArray();
+ }}}
+ '''Wrong:'''
+ {{{
+ #!cpp
+Image *SVGStyledElement::doSomething(PaintInfo &paintInfo)
+{
+    SVGStyledElement *element = static_cast<SVGStyledElement *>(node());
+    const KCDashArray &dashes = dashArray();
+ }}}
+== Include Statements ==
+ * All files must `#include "config.h"` first.
+ * All files must `#include` the primary header second, just after `"config.h"`. So for example, `Node.cpp` should include `Node.h` first, before other files. This guarantees that each header's completeness is tested, to make sure it can be compiled without requiring any other header files be included first.
+ * Other `#include` statements should be in sorted order (case sensitive, as done by the command-line sort tool or the Xcode sort selection command). Don't bother to organize them in a logical order.
+Coding standards can be found at http://www.webkit.org/coding/coding-style.html