[webkit-dev] unwritten rules of webkit style

[Yong Li]

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 
  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/c56ec69b/attachment.html>