[webkit-dev] Proposing style guide change regarding braces on conditional arms

Chris Jerdonek chris.jerdonek at gmail.com
Fri Dec 4 00:13:10 PST 2009

On Thu, Dec 3, 2009 at 10:17 PM, Peter Kasting <pkasting at google.com> wrote:
> On Thu, Dec 3, 2009 at 6:24 PM, Chris Jerdonek <chris.jerdonek at gmail.com>
> wrote:
>> For the people thinking about this, it would be nice if the final
>> policy minimizes (and does not increase) the likelihood of having to
>> modify several lines of surrounding code after touching one line of
>> code.  I don't think this consideration has been raised.
> Do you mean "in the steady state of modifying the code base" or "while files
> aren't compliant with whatever change might get made"?

I meant the former (though my alternative below also reduces the latter).

> I think you mean the
> former, but if so, I'm not sure what policy would serve you best.  Ideally
> you'd want "always use braces", but failing that, each proposal has a
> different set of cases where you do/don't have to change as you touch
> things.

I don't feel strongly about this, but I will provide an example to
illustrate what I mean.

The illustrative case is several "else if" clauses with braces -- only
one of which exceeds one line.  If a code change removes the excess
lines in that one clause, the two rules being considered say you have
to remove the braces from all the clauses -- even though the clauses
are already lined up.  And this change can go back and forth

Several people are already saying they value alignment within
individual if-else control structures more than they value the number
of braces.  So removing the braces from all the clauses in the example
above seems secondary.

An alternative policy is as follows:

(1) If-else control structures must have either braces around all
clauses or braces around no clauses.

(2) A clause with more than one line must be surrounded by braces.

A consequence of this policy is that if-else statements may gradually
converge to braces, but this change would take place only as needed.


More information about the webkit-dev mailing list