[webkit-dev] unwritten rules of webkit style
darin at apple.com
Wed Sep 2 09:31:12 PDT 2009
Thank you for taking this on. This list looks very good. I’d like to
see these in the style guide.
These are indeed WebKit style rules that are not yet in the guide and
should all go in there unless we decide to change the rules. Keep in
mind that these rules evolved from the consensus of people working on
the team. There is no one person who agrees with all of them, and
earlier in the project lifetime we did refine the rules as we go. I
don’t think they are written in stone and could change over time.
On Sep 2, 2009, at 8:40 AM, David Levin wrote:
> 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
The sad thing about this is that the "(C)" is completely pointless,
and has no legal status. But I suppose we're stuck with it.
> Use enums instead of bools for parameters. The one exception is
> function names that start with "set" and take one parameter (e.g.
I think this guideline is a bit too strong.
The rule is to use enums instead of bools for parameters when the
function will be used with boolean constants. If the bool comes from
another bool, there is no problem, but when the bool argument is going
to be a boolean constant such as true or false, we use an enum. I’m
not sure how to put that guideline into a clear easy-to-follow rule.
I would not say "the one exception", but rather "one exception".
> 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).
I'm not sure this is exactly the right way to write the rule, but I
can't think of anything better.
> If a ifdef spans more than a few lines, end it like this:
> #endif // WhateverWasInTheIfdef
This says #ifdef but it’s almost always just #if.
> Do not use static initializers for classes/structs. Use
> DEFINE_STATIC_LOCAL instead (or AtomicallyInitializedStatic if the
> initialization should be threadsafe).
This is more than a coding guideline. It’s a “this won’t even build on
the Mac” rule. It probably needs more elaboration than a single line
in the style guide. Perhaps its own document like RefPtr.
More information about the webkit-dev