Why Google Style Guide for C++ is a deal-breaker
linkedin.comI 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.
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.
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.
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.
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.
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.
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.
I'm sure there are others, but honestly it feels more like the guy has a problem with Java than C++.
> 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.
He wasn't complaining about not calling virtual functions in ctors/dtors; he said that was understandable. He was complaining about two-stage initialization being required for any non-trivial initialization.
He didn't say it was understandable, he said he "wasn't completely against it". That is not the same thing by far.
But the point is that he's misunderstanding, the guideline he posted was the following:
> Avoid doing complex initialization in constructors (in particular, initialization that can fail or that requires virtual method calls). ... Constructors should never call virtual functions or attempt to raise non-fatal failures. If your object requires non-trivial initialization, consider using a factory function or Init() method
consider using is a far cry from *required to use. It also explicitly spelled out the situations in which you should consider using something like a factory method.
- When you need to call virtual methods since a factory method implies the full construction of the object
- When you want to indicate non-fatal failures since a factory method implies being able to do so without exceptions.
If your code doesn't require virtual methods and doesn't need to indicate non-fatal failures, then there is nothing in that particular guideline that's relevant to you.
It's a sensible guideline, especially in an environment where you need to be able to avoid using exceptions.
He also took issue with the following:
> Provide a copy constructor and assignment operator only when necessary. Otherwise, disable them with DISALLOW_COPY_AND_ASSIGN.
The entire point of this guideline is to disallow the compiler from doing anymore magic than is completely necessary. Especially surrounding things like construction and operator overloading, C++ does a lot of 'magic' to keep the user syntax relatively clean, but it can also make the code misleading/hard to understand.
The point is that both guidelines are actually sensible, and nothing in them explicitly prevents you from doing anything the author complained about. The idea of "only when necessary" is not even close to "always" or "never".
I didn't read the entire thing, but a lot of the complaints appeared to be related to his misunderstanding the intent, or taking it to the extreme.
> Constructors should never attempt to raise non-fatal failures
That essentially requires two-stage init for almost any non-trivial initialization.
That's untrue, and for you to make that claim is ridiculous, but it does mean this conversation is no longer worth engaging in.