I think that Google style guide is too detailed for being enforced company-wide, and it actually has a few portability problems (i.e. Visual Studio doesn't support constexpr yet), but I actually agree with about half of the points, and none of them occur to me as a deal breaker.<p>I'd rather have a very small company-wide style guide of maybe 10 points which mainly cares about the public interface of a project. One project might not be able to switch to C++11, but another new project from scratch might decide to make use of all the C++11 bells'n'whistles.<p>When choosing 3rd party libs to integrate with my own code I have made the experience that the simpler the better. Please don't use exceptions or make them optional (some platforms don't have support for exceptions or got them very late, some still have a performance penalty), provide a way to override threading, timing, file i/o, dynamic memory allocation and other platform-specific functions with my own versions, bonus points for providing a C interface so that I can write my own C++ wrapper which fits my own style guide.
I worked on a project that used the Google C++ Style guide for a while - I found it quite painless and mostly sensible.<p>Conversative style guides are useful when you are coding in a team of people with various abilities.
Very good summary. I understand the reason why Google has these restrictions: they have a lot of old C++ code and they try to play it safe, maintain the same code style, etc. However, the modern C++ is a much nicer language than it was 15 years ago. By imposing these restrictions, Google limits the developers productivity and quality of the code. I've had experience integrating large old C/C++ project into the modern C++ world and while it is not a simple task, it can be done with relatively low pain (the biggest challenge was related to making the code exception safe).
I didn't read all of his examples, but I read a few.<p>I'm confused by his issue with calling virtual functions from the constructor. Because of the order in which C++ calls the constructors in a base/parent class hierarchy during construction, calling a virtual function can be dangerous.<p>This is a valid restriction in my opinion. I get that it doesn't have to result in problems, and it can be useful, but in general, the guidelines in that section of the article coincide with whats generally considered good C++ code anyway.<p>The example about the copy constructor being disabled by default. That's pretty sane in my opinion, some of the downsides to C++ are that sometimes you can't tell what's going on when looking at an innocuous statement such as 'a=b'. This policy just greatly tamps down on the possibility of C++ hiding a heck of a lot of 'magic' from you by doing things you didn't necessarily expect.<p>I'm sure there are others, but honestly it feels more like the guy has a problem with Java than C++.