Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google C++ Style Guide Is No Good

eyakubovich.github.io

Post reply on HN
Print view View original

11–20 of 108 posts

Re: Google C++ Style Guide Is No Good

#11

Post by cma »

hendzen wrote: post #5
cma wrote: post #3

> Exceptions vs error codes debate is much like space-vs-tabs so I will sit this one out. GSG forbids exceptions on the ground of “Google’s existing code is not exception-tolerant”. I’m not sure what that refers to. Read "Exceptional C++". It isn't worth trying to support them. It is an exercise in masochism. It isn't at all like tabs-vs-spaces.

it really isn't that hard if you practice RAII properly. I've used C++ exceptions on several large C++ codebases and not run in to major issues.

Template libraries that have to deal with stuff that could throw vs couldn't end up with lots of nearr duplicate code, twice as much needed test coverage, and/or less efficiency if you just cover the could-throw case. And you will still probably get it wrong.

Exceptions can work ok in a GCed language, but I haven't seen them work well otherwise. Maybe it is possible, but in C++ it is a huge trap and isn't worth the extra care that will have to go into everything to avoid really bad problems.

Re: Google C++ Style Guide Is No Good

#13

Post by mav3rick »

Style guide is not meant for agreement, it's a general guideline to ensure that when developers come and go, the style and readability doesn't undergo a massive change. I've found it very useful. One can nitpick each style guide to death.

Re: Google C++ Style Guide Is No Good

#14

Post by saagarjha »

I don’t particularly like the style guide either, but the reasons presented here aren’t great:

> GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, #pragma once is non-standard but widely supported.

I mean, it’s non-standard. What more do you need?

> Although GSG does not forbid them categoricaly, it says to “Avoid using forward declarations where possible”.

The example provided is like the one place you would use a forward declaration. I’m sure it’s fine in this case.

> Marking the function “inline” lets the compiler make the decision. Not marking it inline is a sure way to prevent inlining, unless Link Time Optimizations are turned on.

…for external linkage only. Inside your own code base, the compiler has this authority everywhere.

Re: Google C++ Style Guide Is No Good

#15

Post by Chabs »

jmgao wrote: post #8

I disagree with a lot of the Google C++ style guide, but I disagree with many of the complaints in the post. > Although GSG does not forbid them categoricaly, it says to “Avoid using forward declarations where possible”. However forward declarations are useful in contexts like the following: ... Yes, those are the cases where it isn't possible to avoid forward declarations, so it's fine to use them? > While it’s true…

The most egregious thing for me is:

> in other words, the reader is expected to understand the semantics of an unknown function without consulting the declaration (or documentation).

The idea that the author considers making code as self-documenting as possible at the call site a conceptual mistake is just weird to me.

Re: Google C++ Style Guide Is No Good

#16

Post by forrestthewoods »

> At the same time, every feature that went into the language was vetted for being useful. It was deemed that without the said feature, the code was significantly worse

Talk about an appeal to authority!

Cppcon had an entire talk titled “The Nightmare of Initialization in C++”. C++ initialization is indeed a total clusterfuck. And that’s not a controversial statement!

I’m sure each thing was added to solve a problem. But now there are too many things, and that’s the new problem.

Re: Google C++ Style Guide Is No Good

#17

Post by jcelerier »

saagarjha wrote: post #14

I don’t particularly like the style guide either, but the reasons presented here aren’t great: > GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, #pragma once is non-standard but widely supported. I mean, it’s non-standard. What more do you need? > Although GSG does not forbid them categoricaly, it says to “Avoid using forward declarations where possible”. The example provided is like the one pla…

> I mean, it’s non-standard. What more do you need?

so are most programming languages used in the world. In practice, #pragma once is less trouble than #ifdef ; we had the debate just today in reddit :-) https://www.reddit.com/r/cpp/comments/a14o5q/real_world_prob...

Re: Google C++ Style Guide Is No Good

#18

Post by wyldfire »

hendzen wrote: post #5
cma wrote: post #3

> Exceptions vs error codes debate is much like space-vs-tabs so I will sit this one out. GSG forbids exceptions on the ground of “Google’s existing code is not exception-tolerant”. I’m not sure what that refers to. Read "Exceptional C++". It isn't worth trying to support them. It is an exercise in masochism. It isn't at all like tabs-vs-spaces.

it really isn't that hard if you practice RAII properly. I've used C++ exceptions on several large C++ codebases and not run in to major issues.

Unwinding can be perilous across library boundaries, this is IMO its greatest weakness.

Re: Google C++ Style Guide Is No Good

#19

Post by haberman »

There's a lot here, just a few comments:

> Although GSG does not forbid them categoricaly, it says to “Avoid using forward declarations where possible”. However forward declarations are useful in contexts like the following [...]

Yes, circular data structures are a great reason to use a forward declaration; probably the best one. I think it is a perfect example of why the recommendation against forward declarations is not a prohibition.

Please, please do not forward-declare types you do not own. It constraints the way those types can be refactored. More info here: https://abseil.io/about/compatibility#what-users-must-and-mu...

> The rule basically says that global/static variables with non-trivial constructors and destructors are not allowed. While it’s true that initialization/destruction order of globals between translation units is not defined and can pose problems, this rule is overly prohibitve. Globals like this are not problematic and very useful:

A safe alternative to this is to use a static object inside a function. This can serve the same purpose without the gotchas.

> Even the inter-translation unit ordering is not a huge problem – Stroustrup discusses it in his D&E book.

Experience says otherwise. In the protobuf code-base we have to put a thread-safe initialization check in all of our constructors because we have to statically initialize our default instances, but we can't guarantee these static initializers will run before other static initializers that use them. Static initialization ordering is a real and difficult problem.

Re: Google C++ Style Guide Is No Good

#20

Post by stdplaceholder »

It's ambiguous in the article, and it's not specifically mentioned in the Google C++ Style Guide, but during code review at Google it's likely that a reviewer will object to this code:

  std::vector v;
  v.resize(10, 42);
That form of std::vector::resize is discouraged because nobody can remember which argument is which. A reviewer would probably prefer:

  std::vector v(10);
  std::fill(v.begin(), v.end(), 42);
Or even

  std::vector v{42, 42, 42, 42, 42, 42, 42, 42, 42, 42};
I have some other quibbles with this article

* "Not marking it inline is a sure way to prevent inlining" is totally wrong) * The bit about using-directives is also pretty wrong. See https://abseil.io/tips/153 for why. And the example the author gives is terrible:

  void foo() {
    using namespace std::placeholders;
    std::bind(bar, _1, 2);
This doesn't even need a using-directive.

  void foo() {
    using std::placeholders::_1;
    std::bind(bar, _1, 2);
It's shorter, even.

To summarize, the Google C++ Style Guide is there to assist reviewers in reviewing new code. Contrary to what the author thinks, the guide doesn't prescribe anything. At Google decisions are always left to the reviewer. Read the Abseil libraries to see how the style guide applies and when it is ignored.

Post reply on HN