Google C++ style guide

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

[brianpgordon]

You're right on the money. This passage is particularly damning:

> Rvalue references encourage a programming style that makes heavier use of value semantics. This style is unfamiliar to many developers, and its performance characteristics can be hard to reason about.

It's like, do you know C++ or don't you? Value semantics are C++.

[MichaelMoser123]

Actually they do prohibit those features that arguably cause more damage than benefit.

c++ exceptions? in an unmanaged (runtime engine not managed by some sort of VM) language you can't really assume anything when an exception occurs, you can't assume that you will be able to allocate more memory from the heap, for instance - if the heap is corrupted then this will just not work.

RTTI ? it costs a lot, well and you can do without it; Besides requirement of RTTI (assuming that the library does RTTI) will prevent you from using third party libraries that might be of use. Resolution: skip.

[jsnell]

It's a totally reasonable style guide to adopt with a new project / team. And in fact it's what I chose the last time I started a team doing systems programming. It's well reasoned, and hits my personal sweet spot for the power vs. complexity tradeoff.

C++ has a pretty bad reputation. Possibly deservedly. So unless everyone has already bought fully into C++, the full language is a very hard sell. But C with a few extra conveniences and safety features (strings, unique_ptr, some limited polymorphism) is a much easier one.

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

[mixedbit]

This is actually the main advantage of having detailed coding style guide. Teams don't need to discuss minor details like this over and over again, and can focus on higher level issues. Style rules can be sometimes arbitrary because there is no clear best approach, but it is important that such arbitrary choices are made once, documented, and consistently enforced.

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

[ajtulloch]

For those who are unaware, `clang-format` (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.

[exacube]

This is an older revision of the style guide; they updated the style guide recently to allow lambdas. Other C++11 features were also under review for a while.

[SamReidHughes]

They don't even want you to use rvalue references.

[NickHolt]

There's a few style guides up the path for those interested: 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/

[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!

[anonymousDan]

Finance /HFT. In my last job I worked for a company that sells an algo trading platform written in C++.

[cageface]

Still the language of choice in the world of music production software. This is not a place you'll make a lot of money but the work is far more interesting than the usual CRUD slapdash you do in most dev shops.

[pjmlp]

HPC, games, portable mobile code and embedded systems.

[zura]

Especially remote jobs, outside US.

[xedarius]

Games programmer!

[ddorian43]

db programmer

[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/

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

[skia]

Some coding style guides amount to an obsessive compulsive disorder. They focus on trivialities, like an extra space between parameters or the placement of braces around blocks of code.

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