[webkit-dev] Should we ever change style guidelines? (was Re: Resolution on switch statement indentation)

[Maciej Stachowiak]

Hi Adam,

On Dec 9, 2009, at 11:25 AM, Adam Treat wrote:

> Yep, that does distinguish.  That being said, my personal preference  
> would be
> either to keep the current rule and change the code to meet it or  
> even better
> just eliminate the rule altogether since the community hasn't been  
> following
> it anyways.  That speaks negatively to the real world value of the  
> rule IMHO.

I have thought over your comments about not changing the style  
guidelines at a whim.

I think you make a very good point: the most important thing about the  
style guidelines is that there is one way to do things, and that's  
more important than having the very best way. In particular, anyone  
who is looking to change the style guidelines to best reflect their  
personal preferences is thinking about it the wrong way. And making  
lots of changes could lead to useless code thrash. So, your argument  
almost made me back off on the proposed style rule changes.

However, I don't want to get so set in our ways that we never dare to  
change anything about the style guidelines. One principle that's  
important to the WebKit project is willingness to change things for  
the better, even if there is a short-term cost in terms of disruption.  
We're willing to rename classes and functions, rename files, and break  
internal interfaces if that makes the code better. In the case of the  
style guidelines, how do we balance this way of thinking with the  
desire to avoid thrash and changing on a whim? I think something like  
the following should be our "meta-guidelines" for when to change the  
style guide:

1) If an issue or a particular case is not addressed in the style rule  
at all, then we should be willing to add a new rule.

2) If we failed to fully consider the consequences of a rule when we  
first wrote it down, whether in general or in some particular case,  
then we should consider revising it to address the unanticipated issues.

3) If we have overwhelmingly strong evidence that a particular change  
would aid readability, even though the issue in question had been  
considered before, then we can consider changing. But there should be  
a heavy presumption in favor of the current rule, and if there is not  
consensus on the change, we should lean towards not changing.

4) If the code actually follows a different pattern than the formal  
rule, and we see no strong advantage to the rule, we should consider  
changing the rule to match the code.

I think in the case of case labels, we have a bit of #2 going on. I  
don't think we considered the possibility of blocks inside the case  
label, or at least when we were creating these rules I don't think we  
were aware that there are some cases where using braces is essential,  
so the solution would be to leave them out. The only reason it's every  
truly needed to use braces is if you declare a variable with a type  
that has a constructor or destructor, and I'm pretty sure I at least  
hadn't thought of this when we made the rule.

In the case of braces around single-line clauses, I think we also  
didn't fully consider the impact when you have a lengthy if chain and  
a mix of single-line and multi-line statements. So I think there too,  
#2 applies. However, we definitely *did* consider if statements with  
no else, and two-clause if/else statements, and decided we were ok  
with the consequences of the rule.

That's my thinking on the matter, perhaps others have other opinions.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091209/f3115955/attachment.html>