Google C++ style guide
google-styleguide.googlecode.com
google-styleguide.googlecode.com
But it's not exactly a style guide I'd follow strictly in a new project/team.
> 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++.
But I don't think that's a good enough reason not to prefer values considering the performance and memory usage drawbacks of shared_ptr. unique_ptr is often the best solution in my view.
c++ exceptions? in an unmanaged (runtime engine not managed by some sort of VM) language you can't really assume anything when an exception occurs, you can't assume that you will be able to allocate more memory from the heap, for instance - if the heap is corrupted then this will just not work.
RTTI ? it costs a lot, well and you can do without it; Besides requirement of RTTI (assuming that the library does RTTI) will prevent you from using third party libraries that might be of use. Resolution: skip.
C++ has a pretty bad reputation. Possibly deservedly. So unless everyone has already bought fully into C++, the full language is a very hard sell. But C with a few extra conveniences and safety features (strings, unique_ptr, some limited polymorphism) is a much easier one.
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 why Google mandates camel notation.
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.
I think there are more ambiguous examples, but cant think of them.
MS standards says that if shortened letter combination is longer than 2 words than it's lowered, otherwise everything is uppercase.
e.g. XmlParser, IOStream
But again, everyone can create their own standard and be happy. The only problem occurs when you work with 10 people and everyone is sticking to his own style.
It's similar to `gofmt` in the golang world, and is a really useful tool for enforcing these kind of style guides.
Also, the guide seems to completely miss templates and actually pretty much allow everything in C++ (except lambdas and exceptions). I don't really see the point then.
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.
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.
Much like all other style guides I've come across, there are a lot of hints that I'll find helpful and encourage at our next meetup, but honestly, the only style guide that truly matters is the one you can all agree to in your team and makes sense in your context.
And, I'm not sure if this is just those who share the same water cooler, many C++ devs seem to dislike using STL. I can't figure out why.
1. Holdover from when STL implementations were buggy
2. Holdover from C
3. Avoiding exceptions it might throw if you compile with exceptions off
4. Many STLs are slow and unoptimized.
5. Many parts of the STL are slow, no matter which STL you use
6. Poor allocator support (better, not perfect in c++11)
7. You need guarantees that the STL doesnt provide.
there are more, but those are the big ones.
Proof? I've seen _quite_ the opposite. Sure, these things (and Flash, still) are popular among small/indie devs, but I haven't heard about a single AAA title since ~1995 that didn't used C++.
There is an insane amount of big open source projects out there that use C++. Firefox, Chromium, KDE, .... the list is much longer. Making significant contributions to any of those would most likely be considered experience.
And there are tons of C++ jobs outside the game industry. Not for small-scale web stuff of course, but for client-side stuff, and really huge backends, C++ is still very popular.
Pros are that it performs excellently and const correctness is pretty cool.
Let's get an old fashioned debate started!
It's used to write software where that complexity is a minor cost in return for the performance it provides.
>keywords are overloaded to incomprehensibility
I don't know of a single keyword that is incomprehensible. Only a few keywords are overloaded but they are overloaded in contexts that make it very very clear what they're being used for.
>doesn't make satisfactory guarantees about static initialization
It makes very strong guarantees about static initialization. Static variables declared within a function are initialized when control flow passes through it for the first time, and such initialization is guaranteed to be thread safe. Global variables have three phases to their initialization, zero initialization, static initialization, and then dynamic initialization. Global variables are also initialized in the order that they are defined within a translation unit.
> exception safety is too hard to reason about
Exception safety is easier to reason about in C++ than any other language thanks to RAII.
>it's full of features maintained for backwards compatibility even when they no longer make sense
They make sense because no one wants to rewrite the billions of lines of code that their project might depend on that uses those features. Instead, it makes a lot more sense to just avoid using deprecated or backward compatible features rather than remove them from the language and break a crap load of invaluable software in the process.
>development tools are unacceptably inferior to Java and C#.
This is true.
Other languages (C, D, Ada, Go) provide similar native performance with far less complexity.
> I don't know of a single keyword that is incomprehensible. Only a few keywords are overloaded but they are overloaded in contexts that make it very very clear what they're being used for.
static, virtual, and class are all overloaded in weird ways. But punctuation is the worst: in particular commas, colons, ampersands, and asterisks are overused to absurdity. I'd almost prefer APL-like extra symbols to disambiguate some of the insane template one-liners that I've seen.
> It makes very strong guarantees about static initialization.
Are you saying that the static initialization order fiasco doesn't exist? C# and Java do not suffer from this problem.
> Exception safety is easier to reason about in C++ than any other language thanks to RAII.
I don't even know what to say to this one. Exceptions are notoriously wonky in C++. The language makes you resort to idioms like RAII and copy-swap to use them at all, instead of providing language-level support to solve those problems.
> They make sense because no one wants to rewrite the billions of lines of code that their project might depend on that uses those features. Instead, it makes a lot more sense to just avoid using deprecated or backward compatible features rather than remove them from the language and break a crap load of invaluable software in the process.
And as a consequence the language suffers. Historical reasons are not a valid defense of the present design of the language.
I am reminded of this esr quote:
"While we do not intend to insult the designers of C++, we will not make excuses for them either. They repeatedly made design choices that were well-intentioned, understandable in context, and wrong."
Code coherence can be accomplished with more relaxed rules if you delegate more responsibility to your engineers.
Please elaborate.
You also want your engineers to think by themselves instead of hiding behind a rules book.
—String and Wire (Elements of Modern Programming Style)
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.