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