Changes between Version 5 and Version 6 of Coding Style Guidelines


Ignore:
Timestamp:
Nov 7, 2006, 5:18:29 PM (18 years ago)
Author:
bdash@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Coding Style Guidelines

    v5 v6  
    77 * Code editors should be configured to expand tabs that you type to 4 spaces.
    88
    9 
    109== Braces ==
    1110
    … …  
    2928 }}}
    3029
    31  * Other braces, including for, while, do, switch statements and class definitions — the open brace should go on the same line as the as the control structure.
     30 * Other braces including `for`, `while`, `do`, `switch` statements and class definitions — the open brace should go on the same line as the as the control structure.
    3231
    3332 '''Right:'''
    … …  
    4948
    5049
    51  * 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.
     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.
    5251
    5352 '''Right:'''
    … …  
    110109 }}}
    111110
    112  * Control structures, such as if, while, do and switch — use a single space before the open paren, but no spaces inside the parentheses.
     111 * Control structures such as `if`, `while`, `do` and `switch` — use a single space before the open paren, but no spaces inside the parentheses.
    113112
    114113
    115114== Null, false and 0 ==
    116115
    117  * 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.
    118 
    119  * 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.
     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`.
    120119
    121120 * Tests for null pointers, false values and 0 values should all be done directly, not through an inqueality or equality comparison.
    … …  
    184183 * General Rule: With very few exceptions, prefer embedded capitals instead of underscores for class, function and variable names.
    185184
    186  * C++ and Objective-C classes, interfaces and protocols, and other type names — these names should start with a capital letter and use InterCaps.
     185 * C++ and Objective-C classes, interfaces and protocols, and other type names — these names should start with a capital letter and use !InterCaps.
    187186
    188187 '''Right:'''
    … …  
    216215 }}}
    217216
    218  * 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?)
    219 
    220  * C++ data members should be named like local variables, but with a prefix of m_.
     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_`.
    221220
    222221 * C++ member functions should follow the same naming convention as free functions.
    223222
    224  * 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.
     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.
    225224
    226225 * Objective-C instance variables should be named like local variables but starting with an underscore.
    227226
    228  * Enum members should user InterCaps with an initial capital letter.
    229 
    230  * #defined constants should use all uppercase names with words separated by underscores.
    231 
    232  * 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.
     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.
    233232
    234233 '''Right:'''
    … …  
    298297 }}}
    299298
    300  * 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).
    301 
    302  * 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 &.
     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 `&`.
    303302
    304303 '''Right:'''
    … …  
    323322== Include Statements ==
    324323
    325  * All files must #include "config.h" first.
    326 
    327  * 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.
    328 
    329  * 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.
     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.