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>
125 <li>Boolean expressions at the same nesting level that span multiple lines should
126 have their operators on the left side of the line instead of the right side.
128 <h4 class=
"right">Right:
</h4>
130 return attr-
>name() == srcAttr
131 || attr-
>name() == lowsrcAttr
132 || (attr-
>name() == usemapAttr && attr-
>value().domString()[
0] != '#');
135 <h4 class=
"wrong">Wrong:
</h4>
137 return attr-
>name() == srcAttr ||
138 attr-
>name() == lowsrcAttr ||
139 (attr-
>name() == usemapAttr && attr-
>value().domString()[
0] != '#');
147 <li>Do not place spaces around unary operators.
148 <h4 class=
"right">Right:
</h4>
153 <h4 class=
"wrong">Wrong:
</h4>
159 <li><em>Do
</em> place spaces around binary and ternary operators.
160 <h4 class=
"right">Right:
</h4>
165 return condition ?
1 :
0;
168 <h4 class=
"wrong">Wrong:
</h4>
173 return condition ?
1:
0;
177 <li>Place spaces between control statements and their parentheses.
178 <h4 class=
"right">Right:
</h4>
184 <h4 class=
"wrong">Wrong:
</h4>
191 <li>Do not place spaces between a function and its parentheses, or between a parenthesis and its content.
192 <h4 class=
"right">Right:
</h4>
197 <h4 class=
"wrong">Wrong:
</h4>
205 <h3>Line breaking
</h3>
207 <li>Each statement should get its own line.
208 <h4 class=
"right">Right:
</h4>
216 <h4 class=
"wrong">Wrong:
</h4>
219 if (condition) doIt();
223 <li>An
<code>else
</code> statement should go on the same line as a preceding close brace.
224 <h4 class=
"right">Right:
</h4>
233 <h4 class=
"wrong">Wrong:
</h4>
244 <li>An
<code>else if
</code> statement should be written as an
<code>if
</code> statement when the prior
<code>if
</code> concludes with a
<code>return
</code> statement.
245 <h4 class=
"right">Right:
</h4>
256 <h4 class=
"wrong">Wrong:
</h4>
261 } else if (condition) {
270 <li> Function definitions: place each brace on its own line.
272 <h4 class=
"right">Right:
</h4>
280 <h4 class=
"wrong">Wrong:
</h4>
287 <li> Other braces: place the open brace on the line preceding the code block; place the close brace on its own line.
289 <h4 class=
"right">Right:
</h4>
299 for (int i =
0; i
< 10; i++) {
304 <h4 class=
"wrong">Wrong:
</h4>
311 <li>One-line control clauses should not use braces
312 <h4 class=
"right">Right:
</h4>
318 <h4 class=
"wrong">Wrong:
</h4>
326 <li>Control clauses without a body should use empty braces:
327 <h4 class=
"right">Right:
</h4>
329 for ( ; current; current = current-
>next) { }
332 <h4 class=
"wrong">Wrong:
</h4>
334 for ( ; current; current = current-
>next);
339 <h3>Null, false and
0</h3>
341 <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>
342 <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>
343 <li>Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.
<br>
345 <h4 class=
"right">Right:
</h4>
357 <h4 class=
"wrong">Wrong:
</h4>
359 if (condition == true)
369 <li>In Objective-C, instance variables are initialized to zero automatically. Don't add explicit initializations to nil or NO in an init method.
</li>
374 <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.
375 <h4 class=
"right">Right:
</h4>
382 <h4 class=
"wrong">Wrong:
</h4>
390 <li>Use full words, except in the rare case where an abbreviation would be more canonical and easier to understand.
391 <h4 class=
"right">Right:
</h4>
393 size_t characterSize;
395 short tabIndex; // more canonical
398 <h4 class=
"wrong">Wrong:
</h4>
402 short tabulationIndex; // bizarre
406 <li>Prefix C++ data members with
"m_".
407 <h4 class=
"right">Right:
</h4>
415 <h4 class=
"wrong">Wrong:
</h4>
424 <li>Prefix Objective-C instance variables with
"_".
425 <h4 class=
"right">Right:
</h4>
433 <h4 class=
"wrong">Wrong:
</h4>
442 <li>Precede boolean values with words like
"is" and
"did".
443 <h4 class=
"right">Right:
</h4>
449 <h4 class=
"wrong">Wrong:
</h4>
456 <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.
457 <h4 class=
"right">Right:
</h4>
459 void setCount(size_t); // sets m_count
460 size_t count(); // returns m_count
463 <h4 class=
"wrong">Wrong:
</h4>
465 void setCount(size_t); // sets m_theCount
470 <li>Use descriptive verbs in function names.
471 <h4 class=
"right">Right:
</h4>
473 bool convertToASCII(short*, size_t);
476 <h4 class=
"wrong">Wrong:
</h4>
478 bool toASCII(short*, size_t);
482 <li>Leave meaningless variable names out of function declarations.
483 <h4 class=
"right">Right:
</h4>
485 void setCount(size_t);
488 <h4 class=
"wrong">Wrong:
</h4>
490 void setCount(size_t count);
494 <li>Objective-C method names should follow the Cocoa naming guidelines
—
495 they should read like a phrase and each piece of the selector should
496 start with a lowercase letter and use intercaps.
</li>
497 <li>Enum members should user InterCaps with an initial capital letter.
</li>
498 <li>Prefer const to #define. Prefer inline functions to macros.
</li>
499 <li>#defined constants should use all uppercase names with words separated by underscores.
</li>
500 <li> Macros that expand to function calls or other non-constant computation: these
501 should be named like functions, and should have parentheses at the end, even if
502 they take no arguments (with the exception of some special macros like ASSERT).
503 Note that usually it is preferable to use an inline function in such cases instead of a macro.
<br>
505 <h4 class=
"right">Right:
</h4>
507 #define WBStopButtonTitle() \
508 NSLocalizedString(@
"Stop", @
"Stop button title")
511 <h4 class=
"wrong">Wrong:
</h4>
513 #define WB_STOP_BUTTON_TITLE \
514 NSLocalizedString(@
"Stop", @
"Stop button title")
516 #define WBStopButtontitle \
517 NSLocalizedString(@
"Stop", @
"Stop button title")
520 <li>#define, #ifdef
"header guards" should be named exactly the same as the file (including case), replacing the '.' with a '_'.
521 <h4 class=
"right">Right:
</h4>
524 #ifndef HTMLDocument_h
525 #define HTMLDocument_h
528 <h4 class=
"wrong">Wrong:
</h4>
531 #ifndef _HTML_DOCUMENT_H_
532 #define _HTML_DOCUMENT_H_
537 <h3>Other Punctuation
</h3>
541 <li>Constructors for C++ classes should initialize all of their members using C++
542 initializer syntax. Each member (and superclass) should be indented on a separate
543 line, with the colon or comma preceding the member on that line.
545 <h4 class=
"right">Right:
</h4>
547 MyClass::MyClass(Document* doc)
554 MyOtherClass::MyOtherClass()
560 <h4 class=
"wrong">Wrong:
</h4>
562 MyClass::MyClass(Document* doc) : MySuperClass()
568 MyOtherClass::MyOtherClass() : MySuperClass() {}
571 <li>Pointer types in non-C++ code
— Pointer types should be written with a space between the
572 type and the * (so the * is adjacent to the following identifier if any).
574 <li>Pointer and reference types in C++ code
— Both pointer types and reference types
575 should be written with no space between the type name and the * or
&.
577 <h4 class=
"right">Right:
</h4>
579 Image* SVGStyledElement::doSomething(PaintInfo
& paintInfo)
581 SVGStyledElement* element = static_cast
<SVGStyledElement*
>(node());
582 const KCDashArray
& dashes = dashArray();
585 <h4 class=
"wrong">Wrong:
</h4>
587 Image *SVGStyledElement::doSomething(PaintInfo
&paintInfo)
589 SVGStyledElement *element = static_cast
<SVGStyledElement *
>(node());
590 const KCDashArray
&dashes = dashArray();
595 <h3>#include Statements
</h3>
599 <li>All files must #include
"config.h" first.
601 <li>All files must #include the primary header second, just after
"config.h".
602 So for example, Node.cpp should include Node.h first, before other files.
603 This guarantees that each header's completeness is tested, to make sure it
604 can be compiled without requiring any other header files be included first.
606 <li>Other #include statements should be in sorted order (case sensitive, as
607 done by the command-line sort tool or the Xcode sort selection command).
608 Don't bother to organize them in a logical order.
613 include("../footer.inc");