CppCon 2014: Titus Winters 'The Philosophy of Google's C++ Code'

—
--
The Google C++ Style Guide is a fairly popular guide for C++ coding practices, both at Google and externally, but some of its recommendations often seem dated and have created controversy and perceived tension with more modern C++ In this talk we will focus on the core philosophies underlying that guide, ranging from the common (be consistent) to the unusual (leave an explicit trace for the reader), and debunk the idea that Google's C++ is anything less than modern. We'll discuss how these core ideas inform contentious rules like "No non-const references" and "Don't use exceptions," and how the application of those rules has worked for us in practice, both as developers and reliability engineers (SREs).
--
Titus Winters has spent the past 3 years working on Google's core C++ libraries. He's particularly interested in issues of large scale software engineer and codebase maintenance: how do we keep a codebase of over 100M lines of code consistent and flexible for the next decade? Along the way he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale, and helps maintain the Google C++ Style Guide.
--

*-----*
*-----*

[JB-ndft]

Everything that can possibly fail should be placed outside the constructor and left for the later initialization. Google's no-exception C++ style guide is perfectly compact and gives much better control of the code.

[thought]

"Since they don't know how to design with exceptions" -- this sounds like a massively good reason to avoid using exceptions. The main point is that one can freely use any subset of C++ that one likes. Don't want exceptions? No problem, the standard library supports them but does not require their use.

[Baekstrom]

14:40: Output should never be a parameter. Don't use out parameters. If you are using C++ 17, use structured binding and/or std::optional. If you are using C++ 11, use tuples and std::tie. If you are on some older compiler than that, get a new job, or find SOME other way of avoiding out parameters. Out parameters automatically make the reader unsure about a number of facts about the function: Does the out parameter have to be initialized before I call the function? Does it's initial value matter? If the function fails, can I assume that the variable has not been altered?

[indranilbanerjee]

If anyone from Google is reading I'd like to know a couple of things about the no exceptions rule.
1. How do you signal an error in a function that returns a value? e.g Foo getFoo()? I can think of 3 way
Foo getFoo(Status&)
Status getFoo(Foo&)
pair(Status, Foo) getFoo()

All of these feel clunky is there a better way? If it is this way how do you do it without non-const references?

[thought]

Exceptions don't have to be used as a general purpose error reporting mechanism. Consider the declaration ifstream f("foo.dat"). If no exception is thrown, how do I know that foo.dat was actually opened? You could use the same principle for all constructor that could fail.

[thought]

just wondering why the hate for this cppcon episode? i watched some others and they don't have so many down votes??

[ayushchaurasia]

is he saying that c++ will be replaced by go or some other language in 10 years ???

[thought]

I suppose it's a matter of perspective. If I create an ifstream object and give it a filename that cannot be opened, I don't really get back an "invalid" ifstream. To me it's simply an ifstream that is not open. Any standard algorithm should operate over a container of ifstreams just fine, some may be open and some may not be. If your application requires that all ifstream objects be open and that failure to open one should cause something to happen, then you are free to implement that.

[felipelazzari]

So, how do they use the standard library if it is filled with functions that throws exceptions?
How handling those exceptions are any different from handling your own exceptions?

And last but not least, how do you prevent the construction of a object in a invalid state if you can't throw at construction?

Don't like exceptions? Use other languages then!

[thought]

No, in google style you would pass a pointer. This makes the code "obvious" without reading the prototype, e.g.

[JansenduPlessis]

Thanks :) Got it eventually. Awesome tool.

[thought]

C++ standard library doesn't require use of exceptions. The language supports them, just as it supports other features. Which other language that supports exceptions also has a standard library that really allow you not to use them if you don't like them.

[thought]

nope, no code in youtube comments?? this is the wrong place for the discussion. goto stackoverflow;

[victoreijkhout]

He's asking how many people had more than a year of C++ or Java in school. Apparently no one raises their hand. "My goodness what did you guys study?". Science, my good man, science. Programming is a skill. You pick that up along the way. (And I'm not passing any sort of judgement here. I teach a one-semester C++ class. If it weren't for me, students would learn Matlab, R, or Python.)

[qqiz]

As long as there are no compiler support to flag exception-unsafe code every developer should be considered incompetent. If one has to add 10K+ LOCs in 3 months to a burning project, he/she will miss at least one exception handling problem regardless of competency level .

[Xeverous]

I have to say I'm very dissapointed how someone (at the top position) in my company enforces everyone to use abolutely idolized Google C++ style guide. Max line width - 80, indent - 1 or 2 spaces. The whole codebase is ABOLUTELY UNREADABLE. I asked multiple people and still, no one ever said something good. I can't even start to think about changing/adjusting someone's function if it's 2-3x times longer just because max line width is 80 - and there is not a single exception for this rule. Consistently retarded automaticly-generated line breaks, invisible 2-space indents (especially because formatter leaves braces on the same line) and never-aligned multiple function calls (because there can never be 2 spaces one after another) - so if there are multiple calls of the same functions, but arguments names differ - you gotta have a nice time searching all the common commas that should be aligned

The whole problem ends up in everyone having their own formatter tool/script. Before any editting use your tool, do your day, and use their '70ish years tool before commit. And we don't even work for Google. The codebase has only a few years.

My tip for everyone: wherever are you going to work - ask the interviewers about company's coding style. I'm tired of reading code that has unnecesary long functions due to line splits and barely visible indent.

[Spiderboydk]

Which memes? I didn't notice any.

[marshalcraft]

so google server run on 100 million lines of code? they probably have their own server os and everything done in c++/assembly.

[thought]

Competent developers should be able to write with or without exceptions. At the end of the day exceptions are just another tool. If my team decides not to use them even though I think they're great, it's really not a big deal. But if you're on the team and start crying that you don't get to use your favorite tool because they're so magical or great or whatever, then actually that's a big problem.

[gast]

Good talk. We use some of the same rules. Readability in a large code base is more important than C++ guru style programming. Making exception safe code in C++ is very hard and goes beyond the level of using RAI objects (e.g. rolling back actions). Code does not get clearer when you are not in control anymore of how to leave a function.