2006-02-10 Joost de Valk <jdevalk@opendarwin.org>
[WebKit-https.git] / 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 them e.g. Makefiles).
24
25 <li> The indent size is 4 spaces.
26
27 <li> Code editors should be configured to expand tabs that you type to 4
28 spaces.
29 </ol>
30
31 <h3>Braces</h3>
32
33 <ol>
34 <li> 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. For example:
35
36 <pre>
37     RIGHT:
38     
39         void foo()
40         {
41         }
42         
43         
44     WRONG:
45     
46         void foo() {
47         }
48
49 </pre>
50
51 <li> Loop control structures, including for, while and do statements - the open brace should go on the same line as the as the control structure. 
52
53 <pre>
54     RIGHT:
55     
56         for (int i = 0; i < 10; i++) {
57         }
58                 
59     WRONG:
60     
61         for (int i = 0; i < 10; i++) 
62         {
63         }
64
65 </pre>
66
67 <li> If/else statements - as above, but if there is an else clause, the close brace should go on the same line as the else.
68
69 <pre>
70     RIGHT:
71
72         if (timeToGetCoffee) {
73             buyCoffee(&coffee);
74             chugIt(coffee);
75         } else if (timeToGoHome)
76             outtaHere = true;
77
78
79     WRONG:
80
81         if (timeToGetCoffee)
82         {
83             buyCoffee(&coffee);
84             chugIt(coffee);
85         } else if (timeToGoHome) 
86         {
87             outtaHere = true;
88         }
89         
90         if (timeToGetCoffee) {
91         } 
92         else if (timeToGoHome) 
93             outtaHere = true;
94
95 </ol>
96
97 <h3>Parentheses</h3>
98
99 <ol>
100
101 <li>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.
102
103 <pre>
104     RIGHT:
105
106         int myFunction(int arg1, float arg2);
107         void noArgFunction();
108
109     WRONG:
110         int myFunction (int arg1, float arg2);
111         int myFunction( int arg1 , float arg2 );
112         void noArgFunction ();
113 </pre>
114
115 <li>Control structures, such as if, while, do and switch - use a single space before the open paren, but no spaces inside the parentheses.
116
117 </ol>
118
119 <h3>Names</h3>
120
121 <ol><li>General Rule: With very few exceptions, prefer embedded
122 capitals instead of underscores for class, function and variable
123 names.
124
125 <li>C++ and Objective-C classes, interfaces and protocols, and other
126 type names - these names should start with a capital letter and use
127 InterCaps.
128
129 <pre>
130     RIGHT:
131     
132         class MyImportantClass
133         
134     WRONG:
135     
136         class My_important_class
137         class myImportantClass
138 </pre>
139         
140 <li>Local variables should use interCaps, but the first word should
141 start with a lowercase letter, like this:
142
143 <pre>
144     RIGHT:
145     
146         int myInt;
147         
148     WRONG:
149     
150         int MyInt;
151         int my_int;
152 </pre>
153         
154 <li>Free function names in C++ should follow the same naming
155 conventions as local variables. Most functions should be named to
156 sound like verb phrases, like "openDoor" or
157 "walkAroundTheBlock". (getters, setters, predicates?)
158
159 <li>C++ data members should be named like local variables, but with a
160 prefix of m_.
161
162 <li>C++ member functions should follow the same naming convention as
163 free functions.
164
165 <li>Objective-C methods should follow the usual Cocoa naming style -
166 they should read like a phrase or sentence and each piece of the
167 selector should start with a lowercase letter and use intercaps.
168
169 <li>Objective-C instance variables should be named like local
170 variables but starting with an underscore.
171
172 <li>Pointer and reference types - pointer types should be written with
173 a space between the type name and the * (so the * is adjacent to the
174 following identifier if any). For reference types, the &amp; goes next to
175 the type name.
176
177
178 <li>Enum members should user InterCaps with an initial capital letter.
179
180 <li>#defined constants should use all uppercase names with words
181 separated by underscores.
182
183 <li> Macros that expand to function calls or other non-constant
184      computation: these should be named like functions, and should
185      have parentheses at the end, even if they take no arguments (with
186      the exception of some special macros like ASSERT):
187
188 <pre>
189     RIGHT:
190         #define WBStopButtonTitle()  NSLocalizedString(@"Stop", @"Go/Stop button title when busy")
191
192     WRONG:
193         #define WB_STOP_BUTTON_TITLE  NSLocalizedString(@"Stop", @"Go/Stop button title when busy")
194         #define WBStopButtontitle  NSLocalizedString(@"Stop", @"Go/Stop button title when busy")
195 </pre>
196
197 <li> Acronyms in names: If an identifier includes an acronym, make the
198      acronym all-uppercase or all-lowercase, depending on whether a
199      word in that position would be capitalized or not.
200
201 <pre>
202     RIGHT:
203
204         urlVariable
205         myURLAccessor:
206
207     WRONG:
208
209         uRLVariable
210         myUrlAccessor:
211 </pre>
212 </ol>
213