WebKitSite/coding/coding-style.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
   2 <html>
   3 <head>
   4   <meta content="text/html; charset=ISO-8859-1"
   5  http-equiv="content-type">
   6   <title>WebKit Coding Style Guidelines</title>
   7   <link rel=stylesheet href="../webkitdev.css">
   8 </head>
   9 <body>
  10 <!--begin sidebar -->
  11 <iframe id="sidebar" src="../sidebar.html"></iframe>
  12 <!--end sidebar -->
  13
  14 <h1 id="banner">WebKit Coding Style Guidelines</h1>
  15
  16 <div id="content">
  17
  18
  19 <h3>Indenting</h3>
  20
  21 <ol>
  22 <li> Use spaces to indent. Tabs should not appear in code files (with
  23      the exception of files that require tabs, e.g. Makefiles). We have
  24      a Subversion pre-commit script that enforces this rule for most
  25      source files, preventing commits of files that don't follow this rule.
  26
  27 <li> The indent size is 4 spaces.
  28
  29 <li> Code editors should be configured to expand tabs that you type to 4
  30 spaces.
  31 </ol>
  32
  33 <h3>Braces</h3>
  34
  35 <ol>
  36 <li> Function definitions &mdash; 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:
  37
  38 <pre>
  39     RIGHT:
  40         void foo()
  41         {
  42         }
  43
  44     WRONG:
  45         void foo() {
  46         }
  47 </pre>
  48
  49 <li> Loop control structures, including for, while and do statements &mdash; the open brace should go on the same line as the as the control structure.
  50
  51 <pre>
  52     RIGHT:
  53         for (int i = 0; i < 10; i++) {
  54         }
  55
  56     WRONG:
  57         for (int i = 0; i < 10; i++)
  58         {
  59         }
  60 </pre>
  61
  62 <li> If/else statements &mdash; as above, but if there is an else clause, the close brace should go on the same line as the else.
  63
  64 <pre>
  65     RIGHT:
  66         if (timeToGetCoffee) {
  67             buyCoffee(&coffee);
  68             chugIt(coffee);
  69         } else if (timeToGoHome)
  70             outtaHere = true;
  71
  72     WRONG:
  73         if (timeToGetCoffee)
  74         {
  75             buyCoffee(&coffee);
  76             chugIt(coffee);
  77         } else if (timeToGoHome)
  78         {
  79             outtaHere = true;
  80         }
  81
  82         if (timeToGetCoffee) {
  83         }
  84         else if (timeToGoHome)
  85             outtaHere = true;
  86 </pre>
  87 </ol>
  88
  89 <h3>Parentheses</h3>
  90
  91 <ol>
  92
  93 <li>Function declarations and calls &mdash; 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.
  94
  95 <pre>
  96     RIGHT:
  97         int myFunction(int arg1, float arg2);
  98         void noArgFunction();
  99
 100     WRONG:
 101         int myFunction (int arg1, float arg2);
 102         int myFunction( int arg1 , float arg2 );
 103         void noArgFunction ();
 104 </pre>
 105
 106 <li>Control structures, such as if, while, do and switch &mdash; use a single space before the open paren, but no spaces inside the parentheses.
 107
 108 </ol>
 109
 110 <h3>Names</h3>
 111
 112 <ol><li>General Rule: With very few exceptions, prefer embedded
 113 capitals instead of underscores for class, function and variable
 114 names.
 115
 116 <li>C++ and Objective-C classes, interfaces and protocols, and other
 117 type names &mdash; these names should start with a capital letter and use
 118 InterCaps.
 119
 120 <pre>
 121     RIGHT:
 122         class MyImportantClass
 123
 124     WRONG:
 125         class My_important_class
 126         class myImportantClass
 127 </pre>
 128
 129 <li>Local variables should use interCaps, but the first word should
 130 start with a lowercase letter, like this:
 131
 132 <pre>
 133     RIGHT:
 134         int myInt;
 135
 136     WRONG:
 137         int MyInt;
 138         int my_int;
 139 </pre>
 140
 141 <li>Free function names in C++ should follow the same naming
 142 conventions as local variables. Most functions should be named to
 143 sound like verb phrases, like "openDoor" or
 144 "walkAroundTheBlock". (getters, setters, predicates?)
 145
 146 <li>C++ data members should be named like local variables, but with a
 147 prefix of m_.
 148
 149 <li>C++ member functions should follow the same naming convention as
 150 free functions.
 151
 152 <li>Objective-C methods should follow the usual Cocoa naming style &mdash;
 153 they should read like a phrase or sentence and each piece of the
 154 selector should start with a lowercase letter and use intercaps.
 155
 156 <li>Objective-C instance variables should be named like local
 157 variables but starting with an underscore.
 158
 159 <li>Enum members should user InterCaps with an initial capital letter.
 160
 161 <li>#defined constants should use all uppercase names with words
 162 separated by underscores.
 163
 164 <li> Macros that expand to function calls or other non-constant
 165      computation: these should be named like functions, and should
 166      have parentheses at the end, even if they take no arguments (with
 167      the exception of some special macros like ASSERT):
 168
 169 <pre>
 170     RIGHT:
 171         #define WBStopButtonTitle()  NSLocalizedString(@"Stop", @"Go/Stop button title when busy")
 172
 173     WRONG:
 174         #define WB_STOP_BUTTON_TITLE  NSLocalizedString(@"Stop", @"Go/Stop button title when busy")
 175         #define WBStopButtontitle  NSLocalizedString(@"Stop", @"Go/Stop button title when busy")
 176 </pre>
 177
 178 <li> Acronyms in names: If an identifier includes an acronym, make the
 179      acronym all-uppercase or all-lowercase, depending on whether a
 180      word in that position would be capitalized or not.
 181
 182 <pre>
 183     RIGHT:
 184         urlVariable
 185         myURLAccessor:
 186
 187     WRONG:
 188         uRLVariable
 189         myUrlAccessor:
 190 </pre>
 191 </ol>
 192
 193 <h3>Other Punctuation</h3>
 194
 195 <ol>
 196
 197 <li>Pointer and reference types in C++ code &mdash; Both pointer types and reference types
 198 should be written with no space between the type name and the * or &amp;.
 199
 200 <li>Pointer types in non-C++ code &mdash; Pointer types should be written with a space between the
 201 type and the * (so the * is adjacent to the following identifier if any).
 202
 203 </ol>
 204
 205 <h3>Include Statements</h3>
 206
 207 <ol>
 208
 209 <li>All files must #include "config.h" first.
 210
 211 <li>All files must #include the primary header second, just after "config.h".
 212 So for example, Node.cpp should include Node.h first, before other files.
 213 This guarantees that each header's completeness is tested, to make sure it
 214 can be compiled without requiring any other header files be included first.
 215
 216 <li>Other #include statements should be in sorted order (case sensitive, as
 217 done by the command-line sort tool or the Xcode sort selection command).
 218 Don't bother to organize them in a logical order.
 219
 220 </ol>