
Google C++ style guide - degio
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
======
fhd2
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.

But it's not exactly a style guide I'd follow strictly in a new project/team.

~~~
bjz_
The Google style guide could help explain why the Go team thought that their
language would make more of an impact in C++ land than it actually did.

~~~
dsymonds
Nope. Go was born because large C++ builds were just too darn slow, but that
wasn't due to using a restricted subset of C++. In fact, using a subset of C++
speeds the build up.

------
shmerl
_> Functions should start with a capital letter and have a capital letter for
each new word. No underscores._

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.

~~~
romanovcode
>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.

Exactly. It's matter of preference. I can read TextLikeThis much easier than
text_like_this. Granted I've been developing in C# for past few years so
that's likely the reason.

~~~
yoklov
I don't have a strong opinion either way (I probably like snake case more, but
use camel/pascal case basically everywhere) but this doesn't work as well when
acronyms are involved. e.g. is it XmlParser or XMLParser? I'd say the latter,
but someone else might disagree.

I think there are more ambiguous examples, but cant think of them.

~~~
romanovcode
> is it XmlParser or XMLParser?

MS standards says that if shortened letter combination is longer than 2 words
than it's lowered, otherwise everything is uppercase.

e.g. XmlParser, IOStream

But again, everyone can create their own standard and be happy. The only
problem occurs when you work with 10 people and everyone is sticking to his
own style.

~~~
yoklov
Not every API is that consistent. JavaScript's `XMLHttpRequest`, for
example...

------
ajtulloch
For those who are unaware, `clang-format`
([http://clang.llvm.org/docs/ClangFormat.html](http://clang.llvm.org/docs/ClangFormat.html))
can be used to automatically convert existing C++ code to a given formatting
style (Google, LLVM, a custom style, etc).

It's similar to `gofmt` in the golang world, and is a really useful tool for
enforcing these kind of style guides.

------
mmaldacker
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.

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.

~~~
adamnemecek
> They're finally making the stl algorithms easily usable.

Well, considering they ban use of exceptions and considering that stl does use
exceptions and therefore they cannot use stl, I don't think that they really
care.

~~~
IvyMike
I suspect they either use an STL that has a way to disable exceptions (such as
STLPort) or they disable exceptions using compiler flags, or maybe both.

You may argue that this really brings into question the "S" part of "STL" but
it is done in practice and I'd argue it's not even all that difficult to deal
with.

~~~
pbsd
According to this StackOverflow reply [1], they do use the STL, but don't
catch the (very rare) exceptions.

[1]
[https://stackoverflow.com/a/15564254](https://stackoverflow.com/a/15564254)

------
NickHolt
There's a few style guides up the path for those interested: [http://google-
styleguide.googlecode.com/svn/trunk/](http://google-
styleguide.googlecode.com/svn/trunk/)

------
greggman
As an x googler I had my issues with it

[http://games.greggman.com/game/lets-debate-coding-
style/](http://games.greggman.com/game/lets-debate-coding-style/)

------
eksith
"Use only spaces, and indent 2 spaces at a time." Of course you realize, this
means war.

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.

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.

~~~
yoklov
The big reasons for avoiding the STL are (in my experience)

1\. Holdover from when STL implementations were buggy

2\. Holdover from C

3\. Avoiding exceptions it might throw if you compile with exceptions off

4\. Many STLs are slow and unoptimized.

5\. Many parts of the STL are slow, no matter which STL you use

6\. Poor allocator support (better, not perfect in c++11)

7\. You need guarantees that the STL doesnt provide.

there are more, but those are the big ones.

------
cubbimew
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.

------
nemasu
I love C++, I wish there was more work available that used it. EDIT: Clearly
my issue is where I lived, not the lack of available jobs apparently.

~~~
brianpgordon
I don't really see a lot to like about C++. It's huge and fiendishly complex,
keywords are overloaded to incomprehensibility, it doesn't make satisfactory
guarantees about static initialization, exception safety is too hard to reason
about, it's full of features maintained for backwards compatibility even when
they no longer make sense, and development tools are unacceptably inferior to
Java and C#.

Pros are that it performs excellently and const correctness is pretty cool.

Let's get an old fashioned debate started!

~~~
Kranar
>It's huge and fiendishly complex

It's used to write software where that complexity is a minor cost in return
for the performance it provides.

>keywords are overloaded to incomprehensibility

I don't know of a single keyword that is incomprehensible. Only a few keywords
are overloaded but they are overloaded in contexts that make it very very
clear what they're being used for.

>doesn't make satisfactory guarantees about static initialization

It makes very strong guarantees about static initialization. Static variables
declared within a function are initialized when control flow passes through it
for the first time, and such initialization is guaranteed to be thread safe.
Global variables have three phases to their initialization, zero
initialization, static initialization, and then dynamic initialization. Global
variables are also initialized in the order that they are defined within a
translation unit.

> exception safety is too hard to reason about

Exception safety is easier to reason about in C++ than any other language
thanks to RAII.

>it's full of features maintained for backwards compatibility even when they
no longer make sense

They make sense because no one wants to rewrite the billions of lines of code
that their project might depend on that uses those features. Instead, it makes
a lot more sense to just avoid using deprecated or backward compatible
features rather than remove them from the language and break a crap load of
invaluable software in the process.

>development tools are unacceptably inferior to Java and C#.

This is true.

~~~
brianpgordon
> It's used to write software where that complexity is a minor cost in return
> for the performance it provides.

Other languages (C, D, Ada, Go) provide similar native performance with far
less complexity.

> I don't know of a single keyword that is incomprehensible. Only a few
> keywords are overloaded but they are overloaded in contexts that make it
> very very clear what they're being used for.

static, virtual, and class are all overloaded in weird ways. But punctuation
is the worst: in particular commas, colons, ampersands, and asterisks are
overused to absurdity. I'd almost prefer APL-like extra symbols to
disambiguate some of the insane template one-liners that I've seen.

> It makes very strong guarantees about static initialization.

Are you saying that the static initialization order fiasco doesn't exist? C#
and Java do not suffer from this problem.

> Exception safety is easier to reason about in C++ than any other language
> thanks to RAII.

I don't even know what to say to this one. Exceptions are notoriously wonky in
C++. The language makes you resort to idioms like RAII and copy-swap to use
them at all, instead of providing language-level support to solve those
problems.

> They make sense because no one wants to rewrite the billions of lines of
> code that their project might depend on that uses those features. Instead,
> it makes a lot more sense to just avoid using deprecated or backward
> compatible features rather than remove them from the language and break a
> crap load of invaluable software in the process.

And as a consequence the language suffers. Historical reasons are not a valid
defense of the present design of the language.

I am reminded of this esr quote:

"While we do not intend to insult the designers of C++, we will not make
excuses for them either. They repeatedly made design choices that were well-
intentioned, understandable in context, and wrong."

------
patchhill
Looking at this style guide as a C++ programmer, I'd hate to work at Google.

------
joshvm
FYI, the lint tool referenced in the guide is found here:

[http://google-styleguide.googlecode.com/svn/trunk/cpplint/](http://google-
styleguide.googlecode.com/svn/trunk/cpplint/)

------
shin_lao
It might sound like a good idea to precisely describe how code should be
written, until you realize it's inefficient and useless.

Code coherence can be accomplished with more relaxed rules if you delegate
more responsibility to your engineers.

~~~
adamnemecek
> Code coherence can be accomplished with more relaxed rules if you delegate
> more responsibility to your engineers.

Please elaborate.

~~~
shin_lao
I think consensus through code review is better as compilers and languages
evolve. If you write rules for everything you spend your time checking for
compliance and perhaps rewriting rules instead of relying on a more organic
code quality assurance.

You also want your engineers to think by themselves instead of hiding behind a
rules book.

~~~
cloudwalking
Code style doesn't dictate what your engineers build, it just makes their code
easier to review and maintain. Code smells, foreign conventions, and
inconsistency all make reviewing and editing code harder.

------
teemo_cute
"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."

—String and Wire (Elements of Modern Programming Style)

------
frozenport
C++ Guide: We do not use C++ exceptions.

Python Guide: Exceptions are allowed but must be used carefully.

C++ Guide: Do not use lambda expressions, std::function or std::bind.

Python Guide: Okay for one-liners.

~~~
archena
I've encountered a lot of c++ programmers who seem to dislike a lot of c++;
even refusing to use the STL. Perhaps it's because c++ and Python have
different cultural backgrounds: a lot of early c++ programmers came over
grudgingly from c and continued to program in a c-style.

------
frozenport
Does Google's 80 character limit include the identification sequence?

~~~
brianpgordon
You'd think that with their mountains of cash Google could afford to replace
their engineers' 80-character monochrome terminals.

~~~
dsymonds
Actually you find that many engineers with 30" monitors end up using multiple
side-by-side terminal windows, each set to 80 chars.

