Monday, June 30, 2008 at 3:58 PM
Even when you speak the same language as someone else, you may find differences in spelling, pronunciation, or even vocabulary. While the difference between "color" and "colour" isn't likely to confuse anyone, you might run into trouble if your audience doesn't realize that a car's "boot" is the same as its "trunk." Some of us are still trying to figure out whether we wait "on line," "in line," or whether we simply "queue up."
Computer languages are no different in this regard. When you're working on a large software project, how you express something may be a vital part of the code. At Google, we've adopted a set of conventions intended to give all contributors a common coding vocabulary. This ensures that it's as easy as possible to understand code quickly when reading it, both for the original author and later reviewers. Our coding style covers many areas from formatting (we prefer two-space indentation) to use of language and library features (we only allow multiple interface inheritance, not multiple implementation inheritance).
When we release our own code to the public at Google, we're not just sharing our work with the world, we begin to accept contributions to that code base from the public. Naturally, our own code follows our style guidelines, but until now, contributors to Google Open Source projects haven't had a reference for the Google coding style. This has led to frustration for coders and reviewers, and we believe that it's unfair to ask contributors to use a set of rules that haven't been defined for them. With the recent release of the Google C++ Style Guide, we're changing that.
We don't think that our own style of C++ is the only way to write C++, or even necessarily the best, but we do believe that a style guide to define readability and consistency is a tool we can all use to improve software quality. If you're contributing to a Google Open Source project, you may be referred to our guide sometime soon. We're proud of our Open Source contributions, and we're glad we can make life easier for all of our community contributors.
10 comments:
In the section "Pointer and Reference Expressions", there is a comment saying that spaces on both sides of the * or & is bad; like the following:
type & variable
type * variable
However, there is no justification for this.
I find that spaces on both sides is more readable and harder to miss than the other forms.
I'd like to hear the reasons why the authors think it bad.
Francis, there is an explanation inside of the document:
Coding style and formatting are pretty arbitrary, but a project is much easier to follow if everyone uses the same style. Individuals may not agree with every aspect of the formatting rules, and some of the rules may take some getting used to, but it is important that all project contributors follow the style rules so that they can all read and understand everyone's code easily.
Great work, very nice! Any chance you guys can release your python/java styleguides? :)
I would guess the main reason is that those statements look like arithmetic operations.
Francis,
Let's not start public style debates. There are many equally acceptable styles, and debating them is not productive. In this community, they use these conventions. That's all there is to it.
There's also no justification for saying "hood" rather than "bonnet". In some countries, they just do.
-crt
My only "objection" is about indentation: it should give a clear visual hint on the structure of the code.
In my (rather limited) real-world experience with C++ 2 spaces (or event only 1 in case of public/protected/private) are not enough (especially after you've spent a few hours staring at the code :P)
I find some choices in this guideline to be missing a logical argument.
Why not use exceptions ? What is the argument ? How do you handle errors otherwise, what is your mechanism ?
Why put a space between the reference operator and the variable ? What is the argument ? Is it really more readable ? based on what study ?
I see no reference to templates, you don't use templates at all or anyone can write templates however he wishes ?
Why 2 space indentation ? Why not one space ? Why not three ? Why not tabs and everyone can set the number of spaces in his favorite editor ?
Maybe these are great rules, but please give an argument, explain why these rules are good.
Because otherwise nobody will write code in a way that does not make sense (have no logical argument).
Programming is logic, you can't write logic in an illogical way.
I understand that consistency is the important thing, but why be consistent in somebody's personal taste way and not in a better choice way ?
For the "Why put a space between the reference operator and the variable ?", there is no such thing, I misunderstood the first comment.
The rule for order of includes looks quite strange... Shouldn't it be the opposite order if you want to avoid hidden dependencies?
Just hope the Artistic Style guys (http://astyle.sourceforge.net) can add this Google Style into AStyle.
Post a Comment