Similar but unrelated topic... Does anyone have a good C style guide they like?
Google C++ Style Guide Is No Good
51–60 of 108 posts
Re: Google C++ Style Guide Is No Good
#52I 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."
Re: Google C++ Style Guide Is No Good
#53Perhaps it's a matter of rule-based versus principle-based view of the world.
Generally speaking, in a principle-based system, there is room for different interpretations of the stated principles. Edge cases usually don't require special mention.
In a rule-based system, rules are strictly defined and enforced with little room for interpretation. Anything not explicitly mentioned is a grey area and edge cases often end up amending the rules so they are covered as well.
Sounds to me like the author prefers the rule-based approach and/or is assuming these rules are strictly enforced.
Re: Google C++ Style Guide Is No Good
#54Fun piece of trivia for you: The C++ Core Guidelines referenced in this article are longer than the language spec for Go.
Re: Google C++ Style Guide Is No Good
#55I’m not a huge fan of the GSG, at least the C++ one. It seems to be less about style and more about forbidding scary language features. A language feature only becomes a “foot gun” in the hands of a careless developer. Maybe it’s too idealistic but IMO it’s better to fix the “careless developer” problem at the interview stage, not in a style guideline.
Hire developers who voluntarily follow best practices and use good judgment...don’t try to mandate it with an arbitrary list of forbidden practices.
Re: Google C++ Style Guide Is No Good
#56There 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 profitable it won't, the fact that you say "inline" means nothing.
* Complaining about complex globals initialisers: they directly impact library load time, they do cause breakages on ordering. Yes you could structure your code to avoid ordering issues, but then every developer needs to work for all time to avoid breaking it. Or you could just not use them, and it's not a problem.
* Restricting copies: It should be super easy to tell at a glance if code is going to be needlessly inefficient. Easiest way to ensure that is to make your code fail to compile.
* Exceptions: they add significantly to code size and launch time. The failure modes are hard to reason about. The standard idiom everyone is move to is option or result types. It means you have to handle errors, or be explicit in ignoring them.
* Template meta programming is extremely slow to compile, and very difficult for people to understand. constexpr is easier to read and understand, more efficient to compile, and can also be reused for non-constant cases.
* Boost: if you're using boost then you're requiring all your developers to install boost. Then you need to also ensure that they're all using the same version, and then people can end up requiring multiple versions. Again, super large company, with many many engineers and many projects mean the chances of multiple projects depending on different versions of libraries will cause misery.
* C++11 - Cool, it's 2018, guess what: many machines are running versions of an OS that has a 2018 edition of the C++ standard library. If you compile targeting newer versions of the standard library then you can't ship to those systems, unless you include a copy of the standard library in your binary. Then you have to hope your copy of the standard library doesn't conflict with any loaded by the system's own libraries.
Re: Google C++ Style Guide Is No Good
#57I 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...
"#pragma once" used to cause GCC to launch a game of Tetris instead of compiling your code. Not super relevant today, but a fun fact.
Re: Google C++ Style Guide Is No Good
#58There 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>.
Re: Google C++ Style Guide Is No Good
#59Earlier quoted context omitted.
Using 'likely/unlikely' compiler directives, the instructions in the unlikely error branch can be hoisted out to another area and not significantly affect instruction cache. It still is a branch though.
and exception-based code can have much less branches since you don't need to check every function call for error but instead let the exception propagate from where they can be thrown. e.g. in a hypothetic case where you load a settings file five layers deep, in an error-code-based solution you have potentially 5 branches while in an exception-based solution you only have one
At the cost of predictable performance though. With current implementations, the exceptional path will be several magnitudes (!) slower for cheap functions.
Re: Google C++ Style Guide Is No Good
#60It 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 projects for school or wherever and think that's how enterprise development really works. Unless they have worked on a major project, it's very difficult for them to understand.
But even more important than sytle, it's consistency. You shouldn't use a coding style/standard because it works for google. You should create a coding style that works for your team or organization and stick to it consistently. Oftentimes, keeping to the style is more important than the style itself.