Google C++ Style Guide
-
Continuing the discussion from Multiple active exceptions at once!?:
@RaceProUK said:
So you'd rather have two-step initialisation?
Maybe he works at Google.
While we're at it, can we please talk about the WTF that the Google C++ Style Guide is? Highlights:
- Exceptions are evil
- Since exceptions are evil, have stupid constructors that don't do anything and do the actual work in a magic "Init()" function
- Since operator overloading is evil, write an "equals()" function instead of overloading ==
- Oh, but do overload = (copy/move assignment), because that's somehow perfectly fine again
- You're recommended to declare functions as "inline", although compilers will just ignore that and are better at deciding what to inline anyway
- Somehow, non-const references are evil
- [... (just read them)]
Seriously, why do people keep recommending the Google guidelines? They are inconsistent (see above) and contain some horrible advice (hidden between some good advice that should be common sense).
-
I remember finding out about the Google coding standards WTFs some time ago. I believe at one point they even discouraged use of namespaces! From what I understand the rationale behind all of their decisions is "it makes the program too hard to understand"...um, ok? For who?
EDIT: I love how above where they talk about two-step initialization they have this:
int i; i = f(); // Bad -- initialization separate from declaration.
-
it makes the program too hard to understand
For Java programmers, maybe, who shouldn't even be near a C++ code base in the first place. I mean, I get their argument that too much template magic is hard to understand. But namespaces? Or exceptions?
I love how above where they talk about two-step initialization they have this [...]
Nice catch :D I'm sure we can find even more inconsistencies.
-
* Exceptions are evil
Cool doesn't have exceptions.* Since exceptions are evil, have stupid constructors that don't do anything and do the actual work in a magic "Init()" function
Cool doesn't have constructor functions. Instead, each variable and block expression in the class is initialized in the order they are defined.* Since operator overloading is evil, write an "equals()" function instead of overloading ==
a == bin Cool is syntactic sugar fora.equals(b). Yes, that means the==operator can crash your program due to null pointers. But only on the left hand side.* Oh, but do overload = (copy/move assignment), because that's somehow perfectly fine again
Cool doesn't have operator overloading, but it also doesn't have any way of accessing another object's fields, so if you want to reuse objects, you need to define a function that re-sets the attributes.* You're recommended to declare functions as "inline", although compilers will just ignore that and are better at deciding what to inline anyway
My version of the Cool compiler uses methods defined on theInttype instead of inline addition or subtraction. Also, the!operator onBooleanis implemented in Cool.* Somehow, non-const references are evil
Cool does not have aconstkeyword. However, it does have these keywords, which are forbidden from appearing in any program:abstractcatchdofinalfinallyforforSomeimplicitimportlazyobjectpackageprivateprotectedrequiresreturnsealedthrowtraittrytypevalwithyield.View raw if you want to see the non-fucked up version.
* [... (just read them)]
I am very lazy.
-
I just found a bit where they say that
structs should only contain data and methods that set data. Which is fine, if it wasn't for the fact one of the example methods they give isValidate(); ifValidate()is setting data fields (other thanIsValidor similar), then it's notValidate(), is it?
-
What is it with you and weird languages?
-
In the list of cons for exceptions, they say "Exception safety requires both RAII and different coding practices." Um, do they not even use RAII? Later in that section "Things would probably be different if we had to do it all over again from scratch." so they backed themselves into a corner?
-
I think he's talking about Go. Which, apparently, is Google's answer to the fact that their employees are too stupid to write decent C++ code.
-
their employees are too stupid to write decent C++ code.
I believe that actually, their employees are not allowed to write decent C++ code.
-
They must have had at least one smart person; after all, someone had to write the first Go compiler
-
Go uses multiple return values instead of exceptions. For example, strconv.ParseInt returns an
errorif the number can't be parsed instead of throwing a runtime exception that might not get caught.
-
Until 1.4, the Go compiler was written in C. From 1.5 on, the Go compiler is written in Go.
-
Um, do they not even use RAII?
Which proves my point: They shouldn't be writing C++ code in the first place.
I believe that actually, their employees are not allowed to write decent C++ code.
They must have had at least one smart person
I know quite a few very smart people who work at Google. Which is why I'd really love to know why their C++ guidelines are that stupid.
-
Ah, so Go returns an error that can be ignored instead of throwing an exception that can be ignored
-
instead of throwing a runtime exception that might not get caught.
Instead of that it returns an error that might not be looked at? I don't know Go
, so could you explain why that's better?.
-
I don't know Go, so could you explain why that's better?
Stop! Stop!
Don't start that flamewar!
-
One of the people responsible for Go is also responsible for my avatar: http://research.swtch.com/qart
-
One more reason to have him on my hit list.
-
Support copying and/or moving if it makes sense for your type. Otherwise, disable the implicitly generated special functions that perform copies and moves.
I guess they don't want to mention the Rule Of Five?
-
-
The difference is that the exception is ignored by default and the error gives a compile-time error if you don't handle it or at least explicitly ignore it.
-
So, checked exceptions? Forgive me for relating something I don't know to something I do.
-
Two words: checked exceptions.
Also,
d
-
I guess they don't want to mention the Rule Of Five?
And certainly not the Rule Of Zero, because modern C++ features like exceptions are black magic, right?
-
They're similar to checked exceptions, except that you can handle them in ways other than just "throw" and "catch".
-
Um, don't a majority of languages implement exceptions as ordinary objects?
-
If you are a smart project manager you will realize you cannot have as many ninja C++ programmers as you wish (the type that recites the standard from memory). So instead of betting your success on the flow of this sort of talents, you think about sustainability of the project.
It is interesting however, to see other shitty companies in any small village think they can do away with this and are smarter than Google. When their top talent leaves them, next employee will have no clue how to fix bugs let alone contribute.This is besides the fact that too-smart C++ programmers are only good for Stack Overflow questions, in a real project they are just a pain in the ass.
-
I think this is the real reason for the weird coding standards that Google has - instead of hiring smarter programmers, they just make the language dumber. I guess it works, but it's not pretty.
-
They're similar to checked exceptions, except that you can handle them in ways other than just "throw" and "catch".
That blog posts contains a lot of hacks that you wouldn't have to use if you had exceptions.
This pattern works well, but requires a closure in each function doing the writes; a separate helper function is clumsier to use because the err variable needs to be maintained across calls (try it).
Problems you'll never have with exceptions.
-
In C++, you can even throw around integers, booleans or function pointers if you want.
No, none of that is a good idea, but you can.
-
It's the method of returning exceptions that differs.
-
Yes, but I'd like to read the rationale behind that decision. Send me a link or something that explains why exceptions are returned instead of thrown.
-
If you are a smart project manager you will realize you cannot have as many ninja C++ programmers as you wish (the type that recites the standard from memory).
Yep, that's why you shouldn't be using C++ in the first place unless you either have a good reason to do so or have good C++ programmers. Guidelines that dumb down C++ are not a solution, because they cannot effectively hide the complexity of the language. The only thing they accomplish is making incompetent/uneducated programmers, who really shouldn't touch C++ code in the first place, feel more confident.
-
I think what they really want is "C with Classes"
-
Then they should just use Objective-C. It even has two-step initialization built-in as a language feature!
-
That reminds me, why is Objective-C++ a thing?
-
So you can interface with C++ libraries. I think that's the only reason for its existence.
-
I think the rationale was, as I've seen done in places, that "exceptions are evil". Sometimes this is justified, such as performance in hard real-time systems. Sometimes it's misguided; a particular implementation might not yet be as mature as you want it. Sometimes it's downright dumb, they don't know how to handle them properly.
After a mistake has been around long enough, however, it starts to build up momentum. Now they just have too much code depending on terrible practices to switch to sensible, modern style. Which is a pity, as modern style is far more maintainable.
-
I think the rationale was, as I've seen done in places, that "exceptions are evil".
For a long time, their implementation was so nasty as to make that statement true. It's also been fixed for a long time, but the legacy of the mantra clings on like a blood sucking leech in a latrine outfall.
-
Now they just have too much code depending on terrible practices to switch to sensible, modern style.
That's why a smart man invented gradual refactoring. You know, define some exception-safe wrapper classes, start introducing sane, exception-safe code in the outermost layer of the application and slowly continue working towards the inner layers. That's what everyone else does or at least should do.
-
-
-
I refer to my previous post....
Yuk.
-
You're missing an autorelease there. (Unless you're using ARC.)
-
You don't know that it's missing. Just that it's not showing in that snippet.
I couldn't be bothered to look up what that method was called. ObjC irritates me a lot in the first place, and working out what the full pain looks like was just not worth it for a joke.
-
ObjC irritates me a lot in the first place, and working out what the full pain looks like was just not worth it for a joke.
The syntax is strange, but I've seen worse programming languages. I wrote native iOS apps for some time and I have to confess I actually started to like Objective-C after a while.
-
They must have hired a freelancer.
-
FFS, I remember reading Google guidelines and wondering in which century they are. At some points, they're worst than Samsung and that's an achievement.
-
Just found the article where I originally heard about the :WTF:ness:
-
C++ got not the implementation of exceptions wrong, but their definition.
int Gunc() throw(); // will throw nothing (?) int Hunc() throw(A,B); // can only throw A or B (?)Are the comments correct? Not quite. Gunc() may indeed throw something, and Hunc() may well throw something other than A or B! The compiler just guarantees to beat them senseless if they do… oh, and to beat your program senseless too, most of the time.
Because Gunc() or Hunc() could indeed throw something they promised not to, not only can’t the compiler assume it won’t happen, but the compiler is responsible for being the policeman with the billy club who checks to make sure such a bad thing doesn’t happen undetected. If it does happen, then the compiler must invoke the unexpected() function. Most of the time, that will terminate your program. Why? Because there are only two ways out of unexpected(), neither of which is a normal return. You can pick your poison:
a) Throw instead an exception that the exception specification does allow. If so, the exception propagation continues as it would normally have. But remember that the unexpected()
handler is global — there is only one for the whole program. A global handler is highly unlikely to be smart enough to Do the Right Thing for any given particular case, and the result is to go to terminate(), go directly to terminate(), do not pass catch, do not collect $200.b) Throw instead (or rethrow) an exception that the exception specification (still) doesn’t allow. If the original function allowed a bad_exception type in its exception specification, okay, then it’s a bad_exception that will now get propagated. But if not, then go to terminate(), go directly to terminate()…
Because violated exception specifications end up terminating your program the vast majority of the time, I think it’s legitimate to call that “beat[ing] your program senseless.”
Go Playground - The Go Programming Language
Discover thousands of collaborative articles on 2500+ skills