C++ Guide: We do not use C++ exceptions.
Python Guide: Exceptions are allowed but must be used carefully.
C++ Guide: Do not use lambda expressions, std::function or std::bind.
Python Guide: Okay for one-liners.
Google C++ style guide
31–40 of 55 posts
Re: Google C++ style guide
#32Earlier quoted context omitted.
> They're finally making the stl algorithms easily usable. Well, considering they ban use of exceptions and considering that stl does use exceptions and therefore they cannot use stl, I don't think that they really care.
I suspect they either use an STL that has a way to disable exceptions (such as STLPort) or they disable exceptions using compiler flags, or maybe both. You may argue that this really brings into question the "S" part of "STL" but it is done in practice and I'd argue it's not even all that difficult to deal with.
According to this StackOverflow reply [1], they do use the STL, but don't catch the (very rare) exceptions.
Re: Google C++ style guide
#33The C++ you end up with by following Google's style guide is more of a "C with classes" thing, they prohibit several central features of C++. That said, I understand that they mostly do this to be consistent with their older code bases. But it's not exactly a style guide I'd follow strictly in a new project/team.
The Google style guide could help explain why the Go team thought that their language would make more of an impact in C++ land than it actually did.
Nope. Go was born because large C++ builds were just too darn slow, but that wasn't due to using a restricted subset of C++. In fact, using a subset of C++ speeds the build up.
Re: Google C++ style guide
#34> Functions should start with a capital letter and have a capital letter for each new word. No underscores. Why so? It's Java-ish. Java favors camel notation for some historic reason. C++ on the other hand favors snake notation which is clearly reflected in stdc++. Snake notation is also easier to read, especially if the name contains many words in it. Of course in the end it's a matter of preference, I just wonder w…
>Snake notation is also easier to read, especially if the name contains many words in it. Of course in the end it's a matter of preference.
Exactly. It's matter of preference. I can read TextLikeThis much easier than text_like_this. Granted I've been developing in C# for past few years so that's likely the reason.
Re: Google C++ style guide
#35Does Google's 80 character limit include the identification sequence?
Re: Google C++ style guide
#36> Functions should start with a capital letter and have a capital letter for each new word. No underscores. Why so? It's Java-ish. Java favors camel notation for some historic reason. C++ on the other hand favors snake notation which is clearly reflected in stdc++. Snake notation is also easier to read, especially if the name contains many words in it. Of course in the end it's a matter of preference, I just wonder w…
This is actually the main advantage of having detailed coding style guide. Teams don't need to discuss minor details like this over and over again, and can focus on higher level issues. Style rules can be sometimes arbitrary because there is no clear best approach, but it is important that such arbitrary choices are made once, documented, and consistently enforced.
Re: Google C++ style guide
#37Looking at this style guide as a C++ programmer, I'd hate to work at Google.
Re: Google C++ style guide
#38C++ Guide: We do not use C++ exceptions. Python Guide: Exceptions are allowed but must be used carefully. C++ Guide: Do not use lambda expressions, std::function or std::bind. Python Guide: Okay for one-liners.
I've encountered a lot of c++ programmers who seem to dislike a lot of c++; even refusing to use the STL. Perhaps it's because c++ and Python have different cultural backgrounds: a lot of early c++ programmers came over grudgingly from c and continued to program in a c-style.
Re: Google C++ style guide
#39For those who are unaware, `clang-format` (http://clang.llvm.org/docs/ClangFormat.html) can be used to automatically convert existing C++ code to a given formatting style (Google, LLVM, a custom style, etc).
It's similar to `gofmt` in the golang world, and is a really useful tool for enforcing these kind of style guides.
Re: Google C++ style guide
#40The C++ you end up with by following Google's style guide is more of a "C with classes" thing, they prohibit several central features of C++. That said, I understand that they mostly do this to be consistent with their older code bases. But it's not exactly a style guide I'd follow strictly in a new project/team.
You're right on the money. This passage is particularly damning:
> Rvalue references encourage a programming style that makes heavier use of value semantics. This style is unfamiliar to many developers, and its performance characteristics can be hard to reason about.
It's like, do you know C++ or don't you? Value semantics are C++.