Changes between Version 10 and Version 11 of Coding Style Guidelines


Ignore:
Timestamp:
Jan 10, 2012 1:09:19 PM (10 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  
    1 [[PageOutline]]
    2 
    3 == Indenting ==
    4 
    5  * 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.
    6  * The indent size is 4 spaces.
    7  * Code editors should be configured to expand tabs that you type to 4 spaces.
    8 
    9 == Braces ==
    10 
    11  * 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.
    12 
    13  '''Right:'''
    14  {{{
    15  #!cpp
    16 void foo()
    17 {
    18     // do stuff
    19 }
    20  }}}
    21 
    22  '''Wrong:'''
    23  {{{
    24  #!cpp
    25 void foo() {
    26     // do stuff
    27 }
    28  }}}
    29 
    30  * 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.
    31 
    32  '''Right:'''
    33  {{{
    34  #!cpp
    35 for (int i = 0; i < 10; i++) {
    36     // do stuff
    37 }
    38  }}}
    39 
    40  '''Wrong:'''
    41  {{{
    42  #!cpp
    43 for (int i = 0; i < 10; i++)
    44 {
    45     // do stuff
    46 }
    47  }}}
    48 
    49 
    50  * `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.
    51 
    52  '''Right:'''
    53  {{{
    54  #!cpp
    55 if (timeToGetCoffee) {
    56     buyCoffee(&coffee);
    57     chugIt(coffee);
    58 } else if (timeToGoHome)
    59     // comment on else case
    60     outtaHere = true;
    61  }}}
    62 
    63  '''Wrong:'''
    64  {{{
    65  #!cpp
    66 if (timeToGetCoffee)
    67 {
    68     buyCoffee(&coffee);
    69     chugIt(coffee);
    70 // comment on else case
    71 } else if (timeToGoHome)
    72 {
    73     outtaHere = true;
    74 }
    75  
    76 if (timeToGetCoffee) {
    77 }
    78 else
    79  
    80 // comment on else case
    81  
    82 if (timeToGoHome)
    83     outtaHere = true;
    84  }}}
    85 
    86 
    87 == Parentheses ==
    88 
    89  * 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.
    90 
    91  '''Right:'''
    92  {{{
    93  #!cpp
    94 int myFunction(int arg1, float arg2);
    95 
    96 void noArgFunction(); // for C++ or Objective-C++
    97 
    98 void noArgFunction(void); // for C or Objective-C
    99  }}}
    100 
    101  '''Wrong:'''
    102  {{{
    103  #!cpp
    104 int myFunction (int arg1, float arg2);
    105 
    106 int myFunction( int arg1 , float arg2 );
    107 
    108 void noArgFunction ();
    109  }}}
    110 
    111  * Control structures such as `if`, `while`, `do` and `switch` — use a single space before the open paren, but no spaces inside the parentheses.
    112 
    113 
    114 == Null, false and 0 ==
    115 
    116  * 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`.
    117 
    118  * 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`.
    119 
    120  * Tests for null pointers, false values and 0 values should all be done directly, not through a comparison.
    121 
    122  '''Right:'''
    123  {{{
    124  #!cpp
    125 // test for true
    126 if (foo->isSomething()) {
    127     // code
    128 }
    129    
    130 // test for false
    131 if (!foo->isSomething()) {
    132     // code
    133 }
    134    
    135 // test for non-null
    136 if (ptr) {
    137    // code
    138 }
    139    
    140 // test for null
    141 if (!ptr) {
    142    // code
    143 }
    144    
    145 // test for nonzero
    146 if (count) {
    147     // code
    148 }
    149    
    150 // test for zero
    151 if (!count) {
    152     // code
    153 }
    154  }}}
    155 
    156  '''Wrong:'''
    157  {{{
    158  #!cpp
    159 if (foo->isSomething() == true) {
    160     // code
    161 }
    162    
    163 if (foo->isSomething() != false) {
    164     // code
    165 }
    166    
    167 if (p == NULL) {
    168     // code
    169 }
    170    
    171 if (nil != p) {
    172     // code
    173 }
    174    
    175 if (count == 0) {
    176     // code
    177 }
    178  }}}
    179 
    180 
    181 == Names ==
    182 
    183  * General Rule: With very few exceptions, prefer embedded capitals instead of underscores for class, function and variable names.
    184 
    185  * C++ and Objective-C classes, interfaces and protocols, and other type names — these names should start with a capital letter and use !InterCaps.
    186 
    187  '''Right:'''
    188  {{{
    189  #!cpp
    190 class MyImportantClass;
    191  }}}
    192 
    193  '''Wrong:'''
    194  {{{
    195  #!cpp
    196 class My_important_class;
    197 
    198 class myImportantClass;
    199  }}}
    200 
    201  * Local variables should use interCaps, but the first word should start with a lowercase letter, like this:
    202 
    203  '''Right:'''
    204  {{{
    205  #!cpp
    206 int myInt;
    207  }}}
    208 
    209  '''Wrong:'''
    210  {{{
    211  #!cpp
    212 int MyInt;
    213 
    214 int my_int;
    215  }}}
    216 
    217  * 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?)
    218 
    219  * C++ data members should be named like local variables, but with a prefix of `m_`.
    220 
    221  * C++ member functions should follow the same naming convention as free functions.
    222 
    223  * 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.
    224 
    225  * Objective-C instance variables should be named like local variables but starting with an underscore.
    226 
    227  * Enum members should user !InterCaps with an initial capital letter.
    228 
    229  * `#define`d constants should use all uppercase names with words separated by underscores.
    230 
    231  * 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.
    232 
    233  '''Right:'''
    234  {{{
    235  #!cpp
    236 #define WBStopButtonTitle() \
    237         NSLocalizedString(@"Stop", @"Stop button title")
    238  }}}
    239 
    240  '''Wrong:'''
    241  {{{
    242  #!cpp
    243 #define WB_STOP_BUTTON_TITLE \
    244         NSLocalizedString(@"Stop", @"Stop button title")
    245 
    246 #define WBStopButtontitle \
    247         NSLocalizedString(@"Stop", @"Stop button title")
    248  }}}
    249 
    250  * 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.
    251 
    252  '''Right:'''
    253  {{{
    254  #!cpp
    255 urlVariable
    256 myURLAccessor:
    257  }}}
    258 
    259  '''Wrong:'''
    260  {{{
    261  #!cpp
    262 uRLVariable
    263 myUrlAccessor:
    264  }}}
    265 
    266 
    267 == Other Punctuation ==
    268 
    269  * 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.
    270 
    271  '''Right:'''
    272  {{{
    273  #!cpp
    274 MyClass::MyClass(Document* doc)
    275     : MySuperClass()
    276     , m_myMember(0)
    277     , m_doc(doc)
    278 {
    279 }
    280 
    281 MyOtherClass::MyOtherClass()
    282     : MySuperClass()
    283 {
    284 }
    285  }}}
    286 
    287  '''Wrong:'''
    288  {{{
    289  #!cpp
    290 MyClass::MyClass(Document* doc) : MySuperClass()
    291 {
    292     m_myMember = 0;
    293     m_doc = doc;
    294 }
    295 
    296 MyOtherClass::MyOtherClass() : MySuperClass() {}
    297  }}}
    298 
    299  * 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).
    300 
    301  * 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 `&`.
    302 
    303  '''Right:'''
    304  {{{
    305  #!cpp
    306 Image* SVGStyledElement::doSomething(PaintInfo& paintInfo)
    307 {
    308   SVGStyledElement* element = static_cast<SVGStyledElement*>(node());
    309   const KCDashArray& dashes = dashArray();
    310  }}}
    311 
    312  '''Wrong:'''
    313  {{{
    314  #!cpp
    315 Image *SVGStyledElement::doSomething(PaintInfo &paintInfo)
    316 {
    317     SVGStyledElement *element = static_cast<SVGStyledElement *>(node());
    318     const KCDashArray &dashes = dashArray();
    319  }}}
    320 
    321 
    322 == Include Statements ==
    323 
    324  * All files must `#include "config.h"` first.
    325 
    326  * 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.
    327 
    328  * 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.
     1Coding standards can be found at http://www.webkit.org/coding/coding-style.html