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 <[email protected]> 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
