The C++ you end up with by following Google's style guide is more of a "C with classes" thing, they prohibit several central features of C++. That said, I understand that they mostly do this to be consistent with their older code bases.<p>But it's not exactly a style guide I'd follow strictly in a new project/team.
<i>> Functions should start with a capital letter and have a capital letter for each new word. No underscores.</i><p>Why so? It's Java-ish. Java favors camel notation for some historic reason. C++ on the other hand favors snake notation which is clearly reflected in stdc++. Snake notation is also easier to read, especially if the name contains many words in it. Of course in the end it's a matter of preference, I just wonder why Google mandates camel notation.
For those who are unaware, `clang-format` (<a href="http://clang.llvm.org/docs/ClangFormat.html" rel="nofollow">http://clang.llvm.org/docs/ClangFormat.html</a>) can be used to automatically convert existing C++ code to a given formatting style (Google, LLVM, a custom style, etc).<p>It's similar to `gofmt` in the golang world, and is a really useful tool for enforcing these kind of style guides.
No lambdas allowed? For many other things they say "use within reason", I don't see why they can't say this for lambdas. They're finally making the stl algorithms easily usable. You don't have to write Functors that are in a different place then called.<p>Also, the guide seems to completely miss templates and actually pretty much allow everything in C++ (except lambdas and exceptions). I don't really see the point then.
There's a few style guides up the path for those interested: <a href="http://google-styleguide.googlecode.com/svn/trunk/" rel="nofollow">http://google-styleguide.googlecode.com/svn/trunk/</a>
As an x googler I had my issues with it<p><a href="http://games.greggman.com/game/lets-debate-coding-style/" rel="nofollow">http://games.greggman.com/game/lets-debate-coding-style/</a>
"Use only spaces, and indent 2 spaces at a time." Of course you realize, this means war.<p>Much like all other style guides I've come across, there are a lot of hints that I'll find helpful and encourage at our next meetup, but honestly, the only style guide that truly matters is the one you can all agree to in your team and makes sense in your context.<p>And, I'm not sure if this is just those who share the same water cooler, many C++ devs seem to dislike using STL. I can't figure out why.
It doesn't get any worse than that guide (except maybe EC++ or the FQA).
No RAII, no class invariants, no value semantics, no streams, no operators (which means no custom Iterators, EqualityComparable or even CopyAssignable types! Such a basic feature called "insidious").
Not even mentioning the FUD about newer C++ features.
FYI, the lint tool referenced in the guide is found here:<p><a href="http://google-styleguide.googlecode.com/svn/trunk/cpplint/" rel="nofollow">http://google-styleguide.googlecode.com/svn/trunk/cpplint/</a>
It might sound like a good idea to precisely describe how code should be written, until you realize it's inefficient and useless.<p>Code coherence can be accomplished with more relaxed rules if you delegate more responsibility to your engineers.
"Vigorous programming is concise. A method should contain no unnecessary statements, a class no unnecessary methods, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the programmer make all his methods short, or that he avoid all detail and treat his classes only in design, but that he make every statement tell."<p>—String and Wire (Elements of Modern Programming Style)
C++ Guide: We do not use C++ exceptions.<p>Python Guide: Exceptions are allowed but must be used carefully.<p>C++ Guide: Do not use lambda expressions, std::function or std::bind.<p>Python Guide: Okay for one-liners.