[webkit-dev] unwritten rules of webkit style

[Drew Wilson]

I would agree with Yong Li that fewer style rules are better.
However, what Dave is doing is documenting the *existing* style rules, not
adding new ones. As I suspect we aren't going to suddenly relax the style
guidelines for a mature codebase like WebKit, at the very least having the
style rules all documented will save new contributers some pain.

Thanks for doing this, Dave. I haven't been following the "I HATE
CHANGELOGS" thread, but it would be nice to document the expectations for
ChangeLog comments as part of the style guide.

-atw

On Wed, Sep 2, 2009 at 8:53 AM, Yong Li <yong.li at torchmobile.com> wrote:

>  Personally I don't like most of these. Too many coding rules makes C++
> programming a painful job. Some basic rules are necessary though. I think
> coding rules should be minimized, but not maximized.
>
> BTW, a very basic thing not defined yet: what's the webkit pattern for
> global variables? g_xxx? gXxx? or just same like local variables?
>
> -Yong
>
> ----- Original Message -----
> *From:* David Levin <levin at chromium.org>
> *To:* WebKit Development <webkit-dev at lists.webkit.org>
> *Sent:* Wednesday, September 02, 2009 11:40 AM
> *Subject:* [webkit-dev] unwritten rules of webkit style
>
> * 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
>
> ------------------------------
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090902/6d24e6ef/attachment.html>