[webkit-dev] unwritten rules of webkit style

[David Levin]

*Here's my attempt to state
style/coding issues which aren't in the WebKit style guide, but seem to
be widely recommended.

Please speak up if you think something is incorrect.   If everyone agrees
with these items, then eventually I plan to add them to the WebKit style
document (but I certainly wouldn't mind if someone beat me to it).

Comments
* Comments should look like sentences by beginning with a capital and ending
with a period (punctation).

There should be a *single* space after punctation and before the next
sentence.

There should only be a single space before end of line comments.

Use FIXME: to denote items that need to be addressed in the future.

In copyright entries, don't use ranges for years. Use capital (C) for the
copyright and no comma after the last year.  Example of a well formed
copyright entry:
 * Copyright (C) 2004, 2005, 2006, 2007, 2008 Apple Inc. All rights
reserved.

*Function parameters*
Don't put in parameter names if they don't add information.  A good rule of
thumb is if the parameter type name contains the parameter name (with
trailing numbers or pluralization), then the parameter name isn't needed.
 Usually, there should be a parameter name for bools, strings, and numerical
types.

Use enums instead of bools for parameters.  The one exception is function
names that start with "set" and take one parameter (e.g. setAllowHeaders).

*Classes/Structs*
No blank line before the first item in the class/structs. Add a blank line
before public:, protected:, and private: otherwise.  No blank line after
them.

Each section should be defined only once and they should be in the
order public:, protected:, and private:.

One class per file.  Ideally one struct per file too but sometimes small
structs that are only used in a cpp file may be in place.

*Constants*
*Constants (static const int's) should be named just like a variable and
have no special prefix*
*
*
*Line length*
Don't add explicit line breaks in the middle of a statement unless it is
severely illegible even at wide editor window width (which current code
tends to treats as about 120-180 characters).
*
*
*Braces*
There should be at least one space after a brace and one space before a
closing brace (when there are any characters before or after them
respectively including another brace).
*
*
*Indentation*
Additional clauses in a conditional may be indented 4 extra spaces to
visually separate them from the statement to be executed.


Like this

if (condition1         && condition2)
    statement;


*#include statements*
All ifdef'ed includes should be in a section after all other includes. Don't
use ifdef's around includes if you don't need to.  For example, if you
include a header that has if ENABLE(FEATURE) around its contents, you don't
need to repeat the if ENABLE when including it.
*
#ifdef statements
If a ifdef spans more than a few lines, end it like this:
  #endif // WhateverWasInTheIfdef

Namespaces
If a namespace spans more than a few lines, end it like this
  } // namespace NameOfNamespace

*
*Misc*
Do not use static initializers for classes/structs.  Use DEFINE_STATIC_LOCAL
instead (or AtomicallyInitializedStatic if the initialization should be
threadsafe).

Files who should end with newlines.

Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090902/d9487410/attachment.html>