[webkit-dev] unwritten rules of webkit style

[Yong Li]

I think global variables should start with "g_".

-Yong
  ----- Original Message ----- 
  From: David Levin 
  To: Yong Li 
  Cc: WebKit Development 
  Sent: Wednesday, September 02, 2009 12:30 PM
  Subject: Re: [webkit-dev] unwritten rules of webkit style





  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?


  It was in there but probably not well phrased:


      Constants (static const int's) should be named just like a variable and have no special prefix.


  Perhaps it would be


     Global variables should be named just like a variable and have no special prefix.


  fwiw, I welcome any wording adjustments that anyone may suggest.


  Dave




    -Yong
      ----- Original Message ----- 
      From: David Levin 
      To: WebKit Development 
      Sent: Wednesday, September 02, 2009 11:40 AM
      Subject: [webkit-dev] unwritten rules of webkit style


      Here's my attempt to statestyle/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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090902/875cea68/attachment.html>