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 <[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? > > -Yong > > ----- Original Message ----- > *From:* David Levin <[email protected]> > *To:* WebKit Development <[email protected]> > *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 > [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 > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
