2 $title="WebKit Coding Style Guidelines";
3 include("../header.inc");
6 <style type="text/css">
8 background-color: #F2F2F2;
12 color: #080 !important;
16 color: #f00 !important;
21 <h2>WebKit Coding Style Guidelines</h2>
25 <li> Use spaces, not tabs. Tabs should only appear in files that require them for semantic meaning, like Makefiles.
27 <li> The indent size is 4 spaces.
28 <h4 class="right">Right:</h4>
36 <h4 class="wrong">Wrong:</h4>
44 <li>In a header, code inside a namespace should be indented.
45 <h4 class="right">Right:</h4>
55 } // namespace WebCore
58 <h4 class="wrong">Wrong:</h4>
68 } // namespace WebCore
72 <li>In an implementation file, code inside a namespace should <em>not</em> be indented.
73 <h4 class="right">Right:</h4>
83 } // namespace WebCore
86 <h4 class="wrong">Wrong:</h4>
96 } // namespace WebCore
99 <li>A case label should line up with its switch statement. The case statement is indented.
100 <h4 class="right">Right:</h4>
112 <h4 class="wrong">Wrong:</h4>
128 <li>Do not place spaces around unary operators.
129 <h4 class="right">Right:</h4>
134 <h4 class="wrong">Wrong:</h4>
140 <li><em>Do</em> place spaces around binary and ternary operators.
141 <h4 class="right">Right:</h4>
146 return condition ? 1 : 0;
149 <h4 class="wrong">Wrong:</h4>
154 return condition ? 1:0;
158 <li>Place spaces between control statements and their parentheses.
159 <h4 class="right">Right:</h4>
165 <h4 class="wrong">Wrong:</h4>
172 <li>Do not place spaces between a function and its parentheses, or between a parenthesis and its content.
173 <h4 class="right">Right:</h4>
178 <h4 class="wrong">Wrong:</h4>
186 <h3>Line breaking</h3>
188 <li>Each statement should get its own line.
189 <h4 class="right">Right:</h4>
197 <h4 class="wrong">Wrong:</h4>
200 if (condition) doIt();
204 <li>An else statement should go on the same line as a preceding close brace.
205 <h4 class="right">Right:</h4>
214 <h4 class="wrong">Wrong:</h4>
228 <li> Function definitions: place each brace on its own line.
230 <h4 class="right">Right:</h4>
238 <h4 class="wrong">Wrong:</h4>
245 <li> Other braces: place the open brace on the line preceding the code block; place the close brace on its own line.
247 <h4 class="right">Right:</h4>
257 for (int i = 0; i < 10; i++) {
262 <h4 class="wrong">Wrong:</h4>
269 <li>One-line control clauses should not use braces
270 <h4 class="right">Right:</h4>
276 <h4 class="wrong">Wrong:</h4>
284 <li>Control clauses without a body should use empty braces:
285 <h4 class="right">Right:</h4>
287 for ( ; current; current = current->next) { }
290 <h4 class="wrong">Wrong:</h4>
292 for ( ; current; current = current->next);
297 <h3>Null, false and 0</h3>
299 <li>In C++, the null pointer value should be written as <code>0</code>. In C, it should be written as <code>NULL</code>. In Objective-C and Objective-C++, follow the guideline for C or C++, respectively, but use <code>nil</code> to represent a null Objective-C object.</li>
300 <li>C++ and C <code>bool</code> values should be written as <code>true</code> and <code>false</code>. Objective-C <code>BOOL</code> values should be written as <code>YES</code> and <code>NO</code>.</li>
301 <li>Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.<br>
303 <h4 class="right">Right:</h4>
315 <h4 class="wrong">Wrong:</h4>
317 if (condition == true)
331 <li>Use CamelCase. Capitalize the first letter of a class, struct, protocol, or namespace name. Lower-case the first letter of a variable or function name. Fully capitalize acronyms.
332 <h4 class="right">Right:</h4>
339 <h4 class="wrong">Wrong:</h4>
347 <li>Use full words, except in the rare case where an abbreviation would be more canonical and easier to understand.
348 <h4 class="right">Right:</h4>
350 size_t characterSize;
352 short tabIndex; // more canonical
355 <h4 class="wrong">Wrong:</h4>
359 short tabulationIndex; // bizarre
363 <li>Prefix C++ data members with "m_".
364 <h4 class="right">Right:</h4>
372 <h4 class="wrong">Wrong:</h4>
381 <li>Prefix Objective-C instance variables with "_".
382 <h4 class="right">Right:</h4>
390 <h4 class="wrong">Wrong:</h4>
399 <li>Precede boolean values with words like "is" and "did".
400 <h4 class="right">Right:</h4>
406 <h4 class="wrong">Wrong:</h4>
413 <li>Precede setters with the word "set". Use bare words for getters. Setter and getter names should match the names of the variables being set/gotten.
414 <h4 class="right">Right:</h4>
416 void setCount(size_t); // sets m_count
417 size_t count(); // returns m_count
420 <h4 class="wrong">Wrong:</h4>
422 void setCount(size_t); // sets m_theCount
427 <li>Use descriptive verbs in function names.
428 <h4 class="right">Right:</h4>
430 bool convertToASCII(short*, size_t);
433 <h4 class="wrong">Wrong:</h4>
435 bool toASCII(short*, size_t);
439 <li>Leave meaningless variable names out of function declarations.
440 <h4 class="right">Right:</h4>
442 void setCount(size_t);
445 <h4 class="wrong">Wrong:</h4>
447 void setCount(size_t count);
451 <li>Objective-C method names should follow the Cocoa naming guidelines —
452 they should read like a phrase and each piece of the selector should
453 start with a lowercase letter and use intercaps.</li>
454 <li>Enum members should user InterCaps with an initial capital letter.</li>
455 <li>Prefer const to #define. Prefer inline functions to macros.</li>
456 <li>#defined constants should use all uppercase names with words separated by underscores.</li>
457 <li> Macros that expand to function calls or other non-constant computation: these
458 should be named like functions, and should have parentheses at the end, even if
459 they take no arguments (with the exception of some special macros like ASSERT).
460 Note that usually it is preferable to use an inline function in such cases instead of a macro.<br>
462 <h4 class="right">Right:</h4>
464 #define WBStopButtonTitle() \
465 NSLocalizedString(@"Stop", @"Stop button title")
468 <h4 class="wrong">Wrong:</h4>
470 #define WB_STOP_BUTTON_TITLE \
471 NSLocalizedString(@"Stop", @"Stop button title")
473 #define WBStopButtontitle \
474 NSLocalizedString(@"Stop", @"Stop button title")
477 <li>#define, #ifdef "header guards" should be named exactly the same as the file (including case), replacing the '.' with a '_'.
478 <h4 class="right">Right:</h4>
481 #ifndef HTMLDocument_h
482 #define HTMLDocument_h
485 <h4 class="wrong">Wrong:</h4>
488 #ifndef _HTML_DOCUMENT_H_
489 #define _HTML_DOCUMENT_H_
494 <h3>Other Punctuation</h3>
498 <li>Constructors for C++ classes should initialize all of their members using C++
499 initializer syntax. Each member (and superclass) should be indented on a separate
500 line, with the colon or comma preceding the member on that line.
502 <h4 class="right">Right:</h4>
504 MyClass::MyClass(Document* doc)
511 MyOtherClass::MyOtherClass()
517 <h4 class="wrong">Wrong:</h4>
519 MyClass::MyClass(Document* doc) : MySuperClass()
525 MyOtherClass::MyOtherClass() : MySuperClass() {}
528 <li>Pointer types in non-C++ code — Pointer types should be written with a space between the
529 type and the * (so the * is adjacent to the following identifier if any).
531 <li>Pointer and reference types in C++ code — Both pointer types and reference types
532 should be written with no space between the type name and the * or &.
534 <h4 class="right">Right:</h4>
536 Image* SVGStyledElement::doSomething(PaintInfo& paintInfo)
538 SVGStyledElement* element = static_cast<SVGStyledElement*>(node());
539 const KCDashArray& dashes = dashArray();
542 <h4 class="wrong">Wrong:</h4>
544 Image *SVGStyledElement::doSomething(PaintInfo &paintInfo)
546 SVGStyledElement *element = static_cast<SVGStyledElement *>(node());
547 const KCDashArray &dashes = dashArray();
552 <h3>#include Statements</h3>
556 <li>All files must #include "config.h" first.
558 <li>All files must #include the primary header second, just after "config.h".
559 So for example, Node.cpp should include Node.h first, before other files.
560 This guarantees that each header's completeness is tested, to make sure it
561 can be compiled without requiring any other header files be included first.
563 <li>Other #include statements should be in sorted order (case sensitive, as
564 done by the command-line sort tool or the Xcode sort selection command).
565 Don't bother to organize them in a logical order.
570 include("../footer.inc");