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

71–80 of 108 posts

Re: Google C++ Style Guide Is No Good

#71

Post by anyfoo »

liftbigweights wrote: post #60
anyfoo wrote: post #50

It seems to me that the biggest thing that the author does not know about the provenance of Google's style guide is just how massive Google's projects that this guide applies to really are. A lot of the author's complaints may not make sense on their project with a few engineers, but they are absolutely vital in a code base on which thousands of engineers work on every day. Those engineers often have to touch parts o…

> It seems to me that the biggest thing that the author does not know about the provenance of Google's style guide is just how massive Google's projects that this guide applies to really are. A lot of the author's complaints may not make sense on their project with a few engineers, but they are absolutely vital in a code base on which thousands of engineers work on every day. I agree. People work on their small pet p…

Totally! Consistency in even small things, like "try to order the names of your includes/methods/members alphabetically" take a good significant load of your brain, especially if you are working on a completely different part of the project that you are not fully familiar with.

Re: Google C++ Style Guide Is No Good

#72

Post by eyakubovich »

cletus wrote: post #21

Having written C++ at Google using these (strictly enforced) style guidelines, I actually kind of likes Google's subset of C++. It should be noted that any reasonably sized shop uses a subset of C++. It's insanity not to. It's just a question of what to allow and what not to. Google C++ uses a style of error-handling that's akin to how Go handles errors. Many functions return a util::Status (which would be OK or an e…

I don't accept that any reasonable sized shop needs to subset C++ or insanity will prevail. Any particular slice of code needs to subset the language. You may have some perf sensitive code that can't afford virtual function overhead. Or some code that uses dynamically linked libraries for which RTTI may not work right (so you avoid RTTI there). Perhaps strict determinism is required and you can't use exceptions in this part of the code base.

However this is vastly different than saying that we don't want any of these features anywhere because they might not be appropriate under some conditions. I advocate education so developers can make decisions when to use and not to use certain features (same as selecting the right algorithm -- we don't ban binary search b/c it's harder to understand than linear search).

Same with the "we have tons of programmers" argument -- let's use the lowest common denominator (everything else is "fancy"/"clever") to make sure every line of code is understandable by anyone. Encourage people to learn, not everyone else to dumb down.

Re: Google C++ Style Guide Is No Good

#73

Post by Chyzwar »

larl wrote: post #58
olliej wrote: post #56

There are some super boneheaded comments in here. * "Don't use forward declarations unless necessary" with the counter example of why it's bad, being a case we're they're necessary? * The complaint against "inline" is nonsense. The only thing inline impacts is function linkage. Literally nothing else. If the compiler thinks a function is profitable to inline, it will inline it. If it does not think inlining is profit…

Or even: C++11 - Cool, it's 2018, guess what: Migrating a codebase as large as Google's from C++11 to C++1x is a bunch of work. And a lot of the C++1x goodies are library additions, available in Abseil " rel="nofollow">https://github.com/abseil/abseil-cpp> .

This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.

Re: Google C++ Style Guide Is No Good

#74

Post by dragonwriter »

Chyzwar wrote: post #73
larl wrote: post #58

Earlier quoted context omitted.

Or even: C++11 - Cool, it's 2018, guess what: Migrating a codebase as large as Google's from C++11 to C++1x is a bunch of work. And a lot of the C++1x goodies are library additions, available in Abseil " rel="nofollow">https://github.com/abseil/abseil-cpp> .

This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.

Yes,it motivates companies not to do expensive, unnecessary, high-risk complete replacements.

This may be less fun for developers, but it's not usually a bad decision.

Re: Google C++ Style Guide Is No Good

#75

Post by eyakubovich »

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…

> Yes, those are the cases where it isn't possible to avoid forward declarations, so it's fine to use them? But my point was that it _is_ possible to avoid them by type-punning via void*. Now, one can argue that it's unreasonably bad way to avoid them. But will a reviewer following this guide make the same assumption?

> exit runs global destructors, so if one thread calls exit while some other thread is still doing stuff, it might destroy an object that's in use, leading to explosions.

Or you can structure your code in a way that all your threads join prior to main exiting. Never call exit() or _exit() or even pthread_exit(). I think it's much cleaner. Not to mention that not every program is multi-threaded.

> It is very non-obvious which constructors will get automatically generated, because it depends on the types of the members. `Foo(Foo&& move) = default;` makes it immediately obvious.

Agreed but can you imagine what a simple

struct Point { int x, y; };

become if we were to make everything explicit?

Re: Google C++ Style Guide Is No Good

#76

Post by olliej »

Chyzwar wrote: post #73
larl wrote: post #58

Earlier quoted context omitted.

Or even: C++11 - Cool, it's 2018, guess what: Migrating a codebase as large as Google's from C++11 to C++1x is a bunch of work. And a lot of the C++1x goodies are library additions, available in Abseil " rel="nofollow">https://github.com/abseil/abseil-cpp> .

This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.

Why is that bad?

If the system works, and is fast and efficient enough for the task (which is clearly is), and supports the needed features (there was an article on the things you could do in COBOL a while back that went over this), then what is the benefit?

Sure maintaining something is not as "fun" as writing a new thing, but that doesn't make it better.

Anyway, the "obscure mainframes" isn't true - yes there are cases where the easy path was simulate to emulate a PDP on modern hardware - but there are, for example, COBOL implementations the target .net, in addition to regular unix and windows targeting compilers.

Edit: and I forgot my original reason for replying: the use case for mainframe software is drastically different from consumers.

The big scary mainframe software is generally designed to be essentially a few users, running on a restricted set of homogenous hardware and system software. They are generally specialized so that's all they have to do.

Consumer software is not as forgiving - generally a user expects software they bought 20 years to still work, and likewise will assume that their 10 year old machine should still be able to run new software "because it still works". Look at the commentary on Apple deprecating 32bit software. Or the complaints about Windows N breaking legacy software, while also laughing about the things MS does to keep old things running.

Re: Google C++ Style Guide Is No Good

#77

Post by iokanuon »

olliej wrote: post #56

There are some super boneheaded comments in here. * "Don't use forward declarations unless necessary" with the counter example of why it's bad, being a case we're they're necessary? * The complaint against "inline" is nonsense. The only thing inline impacts is function linkage. Literally nothing else. If the compiler thinks a function is profitable to inline, it will inline it. If it does not think inlining is profit…

>* The complaint against "inline" is nonsense. The only thing inline impacts is function linkage. Literally nothing else.

That's not actually true. At least in clang it lowers the threshold at which a function will become inlined. You can see that happening in this wonderful demonstration by Jason Turner: https://youtu.be/GldFtXZkgYo

Re: Google C++ Style Guide Is No Good

#78

Post by gumby »

anyfoo wrote: post #50

It seems to me that the biggest thing that the author does not know about the provenance of Google's style guide is just how massive Google's projects that this guide applies to really are. A lot of the author's complaints may not make sense on their project with a few engineers, but they are absolutely vital in a code base on which thousands of engineers work on every day. Those engineers often have to touch parts o…

I think the author knows full well via his reference to the guide being adopted elsewhere: he's writing for people who are not at google but adopt big g's standards as they assume they are good. Well they are, but just for google itself (as the guide admits -- it explicitly forbids exceptions not because they are a bad idea but because of so much legacy code).

Re: Google C++ Style Guide Is No Good

#79

Post by olliej »

dragonwriter wrote: post #74
Chyzwar wrote: post #73

Earlier quoted context omitted.

This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.

Yes,it motivates companies not to do expensive, unnecessary, high-risk complete replacements. This may be less fun for developers, but it's not usually a bad decision.

right?

All engineers love rewriting everything, because that's human nature: "I can totally do this better than the last person".

Re: Google C++ Style Guide Is No Good

#80

Post by kazinator »

taspeotis wrote: post #52
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…

> Yes, those are the cases where it isn't possible to avoid forward declarations, so it's fine to use them? The author explicitly mentions how it is possible to avoid forward declarations in those cases: "both of these forward declarations are possible to avoid by type-punning through a void* but it is not a good pattern."

By definition, if avoiding something isn't possible, then there cannot be a "how to avoid".

Why even mention a non-starter choice, like using type punning through a void pointer, as an alternative to a forward declaration.

If a construct is "not possible to avoid" that generally means "not possible to avoid without changing the structure of code and run-time data (let alone changing them to something unsafe)".

Gratuitous forward declarations of C++ classes are "bad" for various reasons. Such as: people sometimes write them just to shut up the compiler, instead of including the right header to provide that declaration. "I'm just using a pointer to this; what's the harm."

It makes perfect sense for a coding standard to advise against this.

Post reply on HN