On Fri, Dec 4, 2009 at 12:13 AM, Chris Jerdonek <chris.jerdo...@gmail.com>wrote:
> 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. > This is actually the precise policy used by the Google C++ Style Guide, which governs the Chromium repository. The problem with this is that it fails to ensure consistency, and the difference between consistently using braces everywhere and consistently not using them on one-line bodies is significant enough that this comes up as a bone of contention in code changes. On Fri, Dec 4, 2009 at 6:30 AM, Adam Treat <tr...@kde.org> wrote: > It seems we keep changing the style guide as fashion changes. It is meant > to > ensure consistency and readability. This is a purely subjective change and > I > think unwarranted. Obviously if I agreed I wouldn't have proposed this change, but it's worth detailing why I disagree. You mention that the style guide is meant to ensure readability. It seems clear, then, that you would support changes to improve readability if they did not decrease consistency; the main problems are that readability is significantly subjective (see some of the expressed opinions in this thread), and changing the rules currently decreases consistency (at least over the short to medium term). I think safety and maintenance cost are also worth considering. My opinion is that this change (as well as Maciej's proposed variant) does not merely affect readability but also improves safety very slightly. (Requiring braces at all times would improve safety more, and decrease maintenance cost, but at perhaps some cost to readability.) I agree with you that our codebase should be consistent. Personally, I would prefer that when we make style guide changes, we actually change the codebase to comply with them. Most of the work here could probably be automated, and I think if we did this it would address the main concern you have. The counterargument to this is that it can obscure blame (probably moreso for a change like the namespace indenting one than this change, but noticeably in both cases). On the other hand, gradual changes obscure blame (gradually, at the changed locations) too, and it's already the case that when digging up the history of a block of code you need to repeatedly skip past uninteresting changes. On Fri, Dec 4, 2009 at 9:39 AM, Adam Treat <tr...@kde.org> wrote: > I don't think we should be changing the style guide for anything besides > clarifications of currently unwritten rules. No matter how the fashion may > change or how developers may change. Changing the rules throws consistency > out the window which is, I believe, the greatest benefit of having a style > guide. Again, I think the consistency argument would be addressed if we actually made code consistent at rule changes. Changing code to make it more readable by the current developer set, when that developer set changes in makeup or opinion, seems like a good thing to me, as it improves productivity and code quality, regardless of whether the change is subjective in nature. As an example I give you the SQLite codebase, which has a consistent set of style rules that are so different from any other code I have ever encountered that I struggle to read and patch the code (and have been told the same by SQLite developers here at Google). You may argue that such a case is far outside any cognitive burden of the rule in question in this thread, but tiny amounts of cognitive friction, spread over a large codebase with many developers and a long lifetime, add up. PK
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
