Why Google Style Guide for C++ is a deal-breaker

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&#x27;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&#x27;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&#x27;n&#x27;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&#x27;t use exceptions or make them optional (some platforms don&#x27;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&#x2F;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&#x27;ve had experience integrating large old C&#x2F;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&#x27;t read all of his examples, but I read a few.<p>I&#x27;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&#x2F;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&#x27;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&#x27;s pretty sane in my opinion, some of the downsides to C++ are that sometimes you can&#x27;t tell what&#x27;s going on when looking at an innocuous statement such as &#x27;a=b&#x27;. This policy just greatly tamps down on the possibility of C++ hiding a heck of a lot of &#x27;magic&#x27; from you by doing things you didn&#x27;t necessarily expect.<p>I&#x27;m sure there are others, but honestly it feels more like the guy has a problem with Java than C++.