

Why Google Style Guide for C++ is a deal-breaker - cledet
http://www.linkedin.com/today/post/article/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker

======
flohofwoe
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.

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.

------
papaf
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.

------
lsh123
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).

------
mreiland
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++.

~~~
TheCoelacanth
> 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.

~~~
mreiland
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.

~~~
TheCoelacanth
> Constructors should never attempt to raise non-fatal failures

That essentially requires two-stage init for almost any non-trivial
initialization.

~~~
mreiland
That's untrue, and for you to make that claim is ridiculous, but it does mean
this conversation is no longer worth engaging in.

