Google C++ Style Guide

I thought it was an old perl convention.

    do_something or die "Somebody set up us the bomb"

In order for us to have simple languages they need to be created from low-level ones.

I also think C++ is too complicated, but it's an amazing powerful language, if you master c++ you can pretty much master any language out there.

People love to hate on C++, but if your going to, at least hate on things that are actually broken.

For instance every non-trivial language with more than a couple of programmers working with it will have some style (maybe less formal) style guide. Python is often hailed as 'executable sudo-code' yet the community has a style guide, pep8. (Interestingly Google has their own style guide for Python.)

There are plenty of valid reasons to hate on C++, but being a cowboy coder isn't really a valid one.

Regardless of language, that is a fairly terse style guide for a company the size of google. Especially when you consider the scale of their applications.

Think about it this way: The web browser you are reading this on was likely written using C++. Here's a link explaining why C++ was chosen: http://programmers.stackexchange.com/questions/41883/why-are... Also, 99% of all commercial games for Xbox 360, PS3 and Wii are written in C++ (probably also with some Lua for scripting). Like it or not, C++ is still the dominant language for these domains.

You should see the size of the style guides for the foundation and steelwork on a sky-scraper!

Of course if you are simply building forts out of sofa cushions then you don't need all this.

'Existing code' refers to Google's codebase, not necessarily the rest of the world. Then they can do things like have their version control diff apps like Mondrian/Rietveld have fixed-width UIs that fit on one page, when they know that everything will fit within 80 chars.

No, Google requires frequent code review. Coders told me when I visited that code which violates standards or raises any kind of compiler warning needs to be discussed with your team before it's committed and will be identified on review. (or nightly build)

Automated rules built into VCS seemed to be the kind of thing nobody there would tolerate.

We used that C++ constant naming convention at EA, too. I like it because it nicely differentiates C++ typed constants from preprocessor constants and macros (which we SPELLED_THUSLY).

It's also used by Apple in all of their Cocoa and CoreFoundation code. An example from CoreFoundation would be their constant CFAllocator references:

    const CFAllocatorRef kCFAllocatorDefault;
    const CFAllocatorRef kCFAllocatorSystemDefault;
    const CFAllocatorRef kCFAllocatorMalloc;
    const CFAllocatorRef kCFAllocatorMallocZone;
    const CFAllocatorRef kCFAllocatorNull;
    const CFAllocatorRef kCFAllocatorUseContext;

I'm actually learning C and I see it a lot in the book examples regarding macros(#define ....)

And useful if the number of days in a week ever changes.

Javascript: http://google-styleguide.googlecode.com/svn/trunk/javascript...

Full list: http://google-styleguide.googlecode.com/svn/trunk/

Well, a couple of reasons. One, as they explained there, C++ exceptions weren't very good when they wrote the bulk of their code. The second reason is that writing exception safe code is hard in C++.

Combining those two, you have code that wasn't written exception defensively having unexpected exit paths due to exceptions and now you've got bugs.

It sounds like they would've included exceptions if they didn't have a legacy codebase. I'm sure that would've added a decent amount to the doc.

Things such as throwing across DLLs, size and time overhead and ABI issues make it not very straight forward to use C++ exceptions on embedded platforms or cross platform software running on several platforms using different tool chains.

One thing that I dislike is that it tries to be overly generic, i.e.

   try { throw 5; } catch (const int& val) { printf("%d\n", val); }
   try { throw "hello_world"; } catch (const char *&val) { puts(val); }

I think it would have been much better (and simpler for implementers!) if they had made std::exception a more fundamental part of the language and required that throw be used on a descendant of it. As it stands if you want to be sure to catch any failure from some external code you end up doing:

  try {
    something();
  } catch (const std::exception& ex) {
    fprintf(stderr, "ERROR: %s\n", ex.what());
  } catch (...) {
    fputs("UNKNOWN ERROR\n", stderr);
  }

My personal opinion is that it's easier to deal with C++ exceptions (warts and all) than to try to avoid them. Just about any method that mutates a STL type can have a heap allocation fail and the only reasonable way to report that is via "throw std::bad_alloc();". Just make sure that your code always follows the principals of RAII ( http://en.wikipedia.org/wiki/RAII ) and you'll be fine.

Click on the triangle next to the guideline; they actually do a good job of justifying most of these rules, including that one.

For an in-depth discussion on the pros and cons of C++ exception usage, check out this article from the CodeProject: http://www.codeproject.com/KB/cpp/cppexceptionsproetcontra.a.... The Google style guideline simply presents one particular opinion on the usage of exceptions. They figure it's easier to maintain source code (particularly in large open source projects) that only uses error codes, than a mix of error codes and exceptions.

As they say that the end "Use common sense and BE CONSISTENT." http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... If you are modifying a project that uses exceptions, then use exceptions. If you then modify a different project that uses error codes instead, then use error codes. Be consistent above all else.

I wonder, too. I sure agree with them that it's possible to mess up with exceptions, sure, but the alternative -- using error codes is also prone to bugs. For starters:

1) It means that you have to check the return value of every call. Miss one, and errors get ignored, which can result memory corruption or worse.

2) Checking return codes after every function call results in terribly verbose code/ Whereas exception-based error handling, when used in the right way, only needs catch() statements in places where the error is actually handled.

2) Every function has to return a status code. This hijacks the return value, meaning that you cannot simply return a value anymore, you always need to use output parameters.