I laughed when I saw this: "If your function crashes upon error, you should append OrDie to the function name.", and then as an example: "OpenFileOrDie". Lol.
What if that was an actual semantic transformation in the language? Naming something XorDie would execute the body of X in a context within which all errors are caught, and if any is found, the call returns NIL or similar?
Easily doable with handler-case, unwind-protect and reader macros, but ugly as sin.
I have always felt that C++ is a language too complicated in a time where keeping it simple is key. The fact that it needs a style guide that long says it all.
People love to hate on C++, but if your going to, at least hate on things that are actually broken.
For instance every non-trivial language with more than a couple of programmers working with it will have some style (maybe less formal) style guide. Python is often hailed as 'executable sudo-code' yet the community has a style guide, pep8. (Interestingly Google has their own style guide for Python.)
There are plenty of valid reasons to hate on C++, but being a cowboy coder isn't really a valid one.
Think about it this way: The web browser you are reading this on was likely written using C++. Here's a link explaining why C++ was chosen: http://programmers.stackexchange.com/questions/41883/why-are... Also, 99% of all commercial games for Xbox 360, PS3 and Wii are written in C++ (probably also with some Lua for scripting). Like it or not, C++ is still the dominant language for these domains.
Obviously we need low level languages. Assembly and C are beautiful languages, even compared to other high level ones. I enjoyed every minute of learning them.
Deep knowledge of C++ is something I would love to have, and I have much respect for those who can grasp all of its concepts.
Regardless of language, that is a fairly terse style guide for a company the size of google. Especially when you consider the scale of their applications.
'Each line of text in your code should be at most 80 characters long. '
We recognize that this rule is controversial, but so much existing code already adheres to it, and we feel that consistency is important.
'Existing code' refers to Google's codebase, not necessarily the rest of the world. Then they can do things like have their version control diff apps like Mondrian/Rietveld have fixed-width UIs that fit on one page, when they know that everything will fit within 80 chars.
Also, many Google developers do a big chunk of their development through SSH windows on a laptop working from home. Laptops have limited screen real estate anyway, and it's really handy to be able to use the default PuTTY terminal size and not have to screw around with resizing it.
It also makes life easier if you like to have several code windows open side by side while you work. I got introduced to this approach a few years ago by a colleague and I've loved it ever since (I actually use vertical splits in Vim FWIW; same difference...).
No, Google requires frequent code review. Coders told me when I visited that code which violates standards or raises any kind of compiler warning needs to be discussed with your team before it's committed and will be identified on review. (or nightly build)
Automated rules built into VCS seemed to be the kind of thing nobody there would tolerate.
We used that C++ constant naming convention at EA, too. I like it because it nicely differentiates C++ typed constants from preprocessor constants and macros (which we SPELLED_THUSLY).
Yeah, it appears it's actually quite common, and I must be one of the last people to be surprised by it. =] I've never been part of a major multi-person C++ project, though, so my stylistic conventions are a mixture of C conventions and the conventions used in the STL. I tend to SPELL_THUSLY even C++ typed constants, though I have also seen them PascalCased (but then, unless context makes it sufficiently clear, they can look like class names).
I think it would have been much better (and simpler for implementers!) if they had made std::exception a more fundamental part of the language and required that throw be used on a descendant of it. As it stands if you want to be sure to catch any failure from some external code you end up doing:
My personal opinion is that it's easier to deal with C++ exceptions (warts and all) than to try to avoid them. Just about any method that mutates a STL type can have a heap allocation fail and the only reasonable way to report that is via "throw std::bad_alloc();". Just make sure that your code always follows the principals of RAII ( http://en.wikipedia.org/wiki/RAII ) and you'll be fine.
Yes, throwing an arbitrary object as an exception is a humorously ridiculous approach.
It's as if every time a machine broke down in a factory, the workmen would have to wheel the machine into the manager's office, shove it on his desk and shout, "there, there's your problem!"... and if the manager didn't grab the machine, it would fly through his back window...
Well, a couple of reasons. One, as they explained there, C++ exceptions weren't very good when they wrote the bulk of their code. The second reason is that writing exception safe code is hard in C++.
Combining those two, you have code that wasn't written exception defensively having unexpected exit paths due to exceptions and now you've got bugs.
It sounds like they would've included exceptions if they didn't have a legacy codebase. I'm sure that would've added a decent amount to the doc.
Things such as throwing across DLLs, size and time overhead and ABI issues make it not very straight forward to use C++ exceptions on embedded platforms or cross platform software running on several platforms using different tool chains.
For an in-depth discussion on the pros and cons of C++ exception usage, check out this article from the CodeProject: http://www.codeproject.com/KB/cpp/cppexceptionsproetcontra.a.... The Google style guideline simply presents one particular opinion on the usage of exceptions. They figure it's easier to maintain source code (particularly in large open source projects) that only uses error codes, than a mix of error codes and exceptions.
As they say that the end "Use common sense and BE CONSISTENT." http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... If you are modifying a project that uses exceptions, then use exceptions. If you then modify a different project that uses error codes instead, then use error codes. Be consistent above all else.
I wonder, too. I sure agree with them that it's possible to mess up with exceptions, sure, but the alternative -- using error codes is also prone to bugs. For starters:
1) It means that you have to check the return value of every call. Miss one, and errors get ignored, which can result memory corruption or worse.
2) Checking return codes after every function call results in terribly verbose code/ Whereas exception-based error handling, when used in the right way, only needs catch() statements in places where the error is actually handled.
2) Every function has to return a status code. This hijacks the return value, meaning that you cannot simply return a value anymore, you always need to use output parameters.
