Changeset 12863 in webkit


Ignore:
Timestamp:
Feb 16, 2006 4:32:02 PM (18 years ago)
Author:
justing
Message:

Changed by Darin on my machine.

  • coding/coding-style.html: Re-merged in changes Darin made to the guidelines a few days back.
Location:
trunk/WebKitSite
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/WebKitSite/ChangeLog

    r12846 r12863  
     12006-02-16  Justin Garcia  <justin.garcia@apple.com>
     2
     3        Changed by Darin on my machine.
     4
     5        * coding/coding-style.html: Re-merged in changes Darin made to the guidelines
     6        a few days back.
     7
    182006-02-16  Joost de Valk  <jdevalk@opendarwin.org>
    29
  • trunk/WebKitSite/coding/coding-style.html

    r12839 r12863  
    99
    1010<ol>
    11 <li> Use spaces to indent. Tabs should not appear in code files (with the exception of files that require them e.g. Makefiles).</li>
     11<li> Use spaces to indent. Tabs should not appear in code files (with the exception of files that require tabs, e.g. Makefiles).
     12     We have a Subversion pre-commit script that enforces this rule for most
     13     source files, preventing commits of files that don't follow this rule.
     14</li>
    1215<li> The indent size is 4 spaces.</li>
    1316<li> Code editors should be configured to expand tabs that you type to 4 spaces.</li>
     
    1619<h3>Braces</h3>
    1720<ol>
    18 <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:<br />
     21<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:<br />
    1922
    2023<h4 style="color: #008000 !important !important">Right:</h4>
     
    3336</pre>
    3437</li>
    35 <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.<br />
     38<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.<br />
    3639
    3740<h4 style="color: #008000 !important">Right:</h4>
     
    5053}
    5154</pre>
    52 <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. Also, one-line  if or else clauses should not get braces.<br />
    53 
     55<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.
     56     Also, one-line if or else clauses should not get braces.<br />
    5457<h4 style="color: #008000 !important">Right:</h4>
    5558<pre style="background-color: #F2F2F2">
     
    9093<h3>Parentheses</h3>
    9194<ol>
    92 <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.<br />
     95<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.
     96    Do use a single space after commas that separate arguments.<br />
    9397
    9498<h4 style="color: #008000 !important">Right:</h4>
    9599<pre style="background-color: #F2F2F2">
    96100int myFunction(int arg1, float arg2);
    97        
     101
    98102void noArgFunction(); // for C++ or Objective-C++
    99        
     103
    100104void noArgFunction(void); // for C or Objective-C
    101105</pre>
     
    104108<pre style="background-color: #F2F2F2">
    105109int myFunction (int arg1, float arg2);
    106        
     110
    107111int myFunction( int arg1 , float arg2 );
    108        
     112
    109113void noArgFunction ();
    110114</pre>
    111115</li>
    112116
    113 <li>Control structures, such as if, while, do and switch - use a single space before the open paren, but no spaces inside the parentheses.
     117<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.
    114118
    115119</li>
     
    184188<ol>
    185189<li>General Rule: With very few exceptions, prefer embedded capitals instead of underscores for class, function and variable names.</p></li>
    186 <li>C++ and Objective-C classes, interfaces and protocols, and other type names - these names should start with a capital letter and use InterCaps.<br />
     190<li>C++ and Objective-C classes, interfaces and protocols, and other type names &emdash; these names should start with a capital letter and use InterCaps.<br />
    187191
    188192<h4 style="color: #008000 !important">Right:</h4>
     
    218222<li>C++ data members should be named like local variables, but with a prefix of m_.</li>
    219223<li>C++ member functions should follow the same naming convention as free functions.</li>
    220 <li>Objective-C methods should follow the usual Cocoa naming style - they should read like a phrase or sentence and each piece of the selector should start with a lowercase letter and use intercaps.</li>
     224<li>Objective-C methods should follow the usual Cocoa naming style &mdash;
     225they should read like a phrase or sentence and each piece of the selector should start with a lowercase letter and use intercaps.</li>
    221226<li>Objective-C instance variables should be named like local variables but starting with an underscore.</li>
    222 <li>Pointer and reference types - pointer types should be written with a space between the type name and the * (so the * is adjacent to the following identifier if any). For reference types, the &amp; goes next to the type name.</li>
    223227<li>Enum members should user InterCaps with an initial capital letter.</li>
    224228<li>#defined constants should use all uppercase names with words separated by underscores.</li>
     
    241245</li>
    242246
    243 <li> Acronyms in names: If an identifier includes an acronym, make the acronym all-uppercase or all-lowercase, depending on whether a word in that position would be capitalized or not.<br />
     247<li> Acronyms in names: If an identifier includes an acronym, make the acronym all-uppercase
     248     or all-lowercase, depending on whether a word in that position would be capitalized or not.<br />
    244249
    245250<h4 style="color: #008000 !important">Right:</h4>
     
    256261</li>
    257262</ol>
     263
     264<h3>Other Punctuation</h3>
     265
     266<ol>
     267
     268<li>Pointer and reference types in C++ code &mdash; Both pointer types and reference types
     269should be written with no space between the type name and the * or &amp;.
     270
     271<li>Pointer types in non-C++ code &mdash; Pointer types should be written with a space between the
     272type and the * (so the * is adjacent to the following identifier if any).
     273
     274</ol>
     275
     276<h3>Include Statements</h3>
     277
     278<ol>
     279
     280<li>All files must #include "config.h" first.
     281
     282<li>All files must #include the primary header second, just after "config.h".
     283So for example, Node.cpp should include Node.h first, before other files.
     284This guarantees that each header's completeness is tested, to make sure it
     285can be compiled without requiring any other header files be included first.
     286
     287<li>Other #include statements should be in sorted order (case sensitive, as
     288done by the command-line sort tool or the Xcode sort selection command).
     289Don't bother to organize them in a logical order.
     290
     291</ol>
     292
    258293<?php
    259294        include("../footer.inc");
Note: See TracChangeset for help on using the changeset viewer.