Google C++ Style Guide


  • Winner of the 2016 Presidential Election

    Continuing the discussion from Multiple active exceptions at once!?:

    @asdf said:

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

  • Winner of the 2016 Presidential Election

    @LB_ said:

    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?

    @LB_ said:

    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.


  • β™Ώ

    @asdf said:

    * Exceptions are evil

    Cool doesn't have exceptions.

    @asdf said:

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

    @asdf said:

    * Since operator overloading is evil, write an "equals()" function instead of overloading ==

    a == b in Cool is syntactic sugar for a.equals(b). Yes, that means the == operator can crash your program due to null pointers. But only on the left hand side.

    @asdf said:

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

    @asdf said:

    * 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 the Int type instead of inline addition or subtraction. Also, the ! operator on Boolean is implemented in Cool.

    @asdf said:

    * Somehow, non-const references are evil

    Cool does not have a const keyword. However, it does have these keywords, which are forbidden from appearing in any program: abstract catch do final finally for forSome implicit import lazy object package private protected requires return sealed throw trait try type val with yield.

    View raw if you want to see the non-fucked up version.

    @asdf said:

    * [... (just read them)]

    I am very lazy.


  • SockDev

    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 is Validate(); if Validate() is setting data fields (other than IsValid or similar), then it's not Validate(), is it?


  • SockDev

    What is it with you and weird languages? :stuck_out_tongue:



  • 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?


  • Winner of the 2016 Presidential Election

    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.



  • @asdf said:

    their employees are too stupid to write decent C++ code.

    I believe that actually, their employees are not allowed to write decent C++ code.


  • SockDev

    They must have had at least one smart person; after all, someone had to write the first Go compiler :smile:


  • β™Ώ

    Go uses multiple return values instead of exceptions. For example, strconv.ParseInt returns an error if 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.


  • Winner of the 2016 Presidential Election

    @LB_ said:

    Um, do they not even use RAII?

    Which proves my point: They shouldn't be writing C++ code in the first place.

    @LB_ said:

    I believe that actually, their employees are not allowed to write decent C++ code.

    @RaceProUK said:

    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.


  • SockDev

    Ah, so Go returns an error that can be ignored instead of throwing an exception that can be ignored :stuck_out_tongue:



  • @ben_lubar said:

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


  • Winner of the 2016 Presidential Election

    @LB_ said:

    I don't know Go, so could you explain why that's better?

    Stop! Stop! :fa_stop: :busstop:

    Don't start that flamewar!


  • β™Ώ

    One of the people responsible for Go is also responsible for my avatar: http://research.swtch.com/qart


  • Winner of the 2016 Presidential Election

    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.


  • SockDev

    Two words: checked exceptions.

    Also, :hanzo:d


  • Winner of the 2016 Presidential Election

    @LB_ said:

    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?


  • BINNED

    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.


  • Winner of the 2016 Presidential Election

    @ben_lubar said:

    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.


  • Winner of the 2016 Presidential Election

    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.


  • Winner of the 2016 Presidential Election

    @dse said:

    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"


  • Winner of the 2016 Presidential Election

    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?


  • Winner of the 2016 Presidential Election

    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.


  • Discourse touched me in a no-no place

    @Kian said:

    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.


  • Winner of the 2016 Presidential Election

    @Kian said:

    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.


  • Winner of the 2016 Presidential Election

    @asdf said:

    Objective-C

    :donotwant.yuk:


  • Discourse touched me in a no-no place

    @sloosecannon said:

    [[[DoNotWant alloc] init] yuk];

    Objective-CTFY


  • Winner of the 2016 Presidential Election

    I refer to my previous post....
    Yuk.


  • Winner of the 2016 Presidential Election

    You're missing an autorelease there. (Unless you're using ARC.)


  • Discourse touched me in a no-no place

    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.


  • Winner of the 2016 Presidential Election

    @dkf said:

    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:
    https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker



  • 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.”


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.