Some questions on Google C++ Style Guide

Why do you even care? Are you working at Google? Is anyone forcing you to use their style?

I care, because I want to know the reasoning behind those guidelines.

Quote:

Original post by Giedrius 1. Why is all lowercase better than mixed case? It seems to me that it is a lot harder to perceive the seperate words in an all lowercase variable name than it is in a mixed case.

It's not better. It is consistent with STL style.

Quote:

2. Why should the class members be suffixed rather than prefixed? I see a huge advantage of prefixing member variables, simply because you may type 'm_', 'm', '_' or any other prefix, press ctrl+space and see a complete sorted list of your member variables in the intellisense window. (Assuming that you use Visual Studio).

Because leading underscore, even if under slightly different semantics, is reserved for use by compiler.

And underscore is used to keep same name of a variable, reducing mental load when reading code. foo_ - variable, foo() getter, set_foo() setter.

Quote:

3. While I agree with the way they suggest naming your functions, I don't agree with the suggested way of naming your accessor functions. I don't see why the getter functions shouldn't be prefixed with "get_" prefix. This would give the same intellisense advantage as prefixing your variable names.

Google isn't all that big on intellisense. Being a Microsoft product and all that. get_ is redundant. foo->get_count() isn't any more meaningful than foo->count(). Obviously it's a get, since it returns something.

And Google doesn't have all that many ctrl-space coders, so it's not that big a deal.

It doesn't really make sense to say that all lowercase is "better" than mixed case, just that this convention treats it as so. Conventions are arbitrary and subjective.

It could simply be that Google wanted to follow the Standard C++ Library conventions, and saw mixing camelcase and underscores as ugly. It could be that the Google C++ style predates effective C++ intellisense (I gather its only in the last few versions of MSVC that it became reliable) or maybe Google employees tended not to work with such dev environments (again, that might be historical).

Coding conventions are about consistency. As long as the convention is adhered to, it doesn't really matter unless the convention has a major flaw - for example common uses of Hungarian notation that impose a burden on the programmer for little reward.

Quote:

Original post by Antheus Because leading underscore, even if under slightly different semantics, is reserved for use by compiler.

...in the global namespace, which class members are not. And we're talking about class members, which renders your argument invalid. The only case where your argument would be valid is two leading underscores or a leading underscore and an uppercase letter, of which neither are used in Google's style.

I'm not biased towards or away from Google's style; I'm simply stating a clarification.

Quote:

Original post by nullsquared ...in the global namespace, which class members are not. And we're talking about class members, which renders your argument invalid. The only case where your argument would be valid is two leading underscores or a leading underscore and an uppercase letter, of which neither are used in Google's style.

While that makes sense to compiler, a human should see anything starting with underscore as compiler-specific.

Putting them last solves this problem.

Quote:

Original post by Antheus a human should see anything starting with underscore as compiler-specific.

What is your reasoning in doing so? I'm sure anyone capable of programming is capable of recognizing a double underscore or a capital letter following an underscore - they stand out like a sore thumb compared to an underscore followed by lowercase letter. If not, I suggest a font change because you must be programming in Comic Sans MS or something.

For example:

__foo_Bar_foobar

First two stand out.

Or this issue may be avoided by having a 'm' or 'm_' prefix, also making it possible to use intellisense more efficiently.

Quote:

Original post by nullsquared Quote: Original post by Antheus a human should see anything starting with underscore as compiler-specific. What is your reasoning in doing so? I'm sure anyone capable of programming is capable of recognizing a double underscore or a capital letter following an underscore - they stand out like a sore thumb compared to an underscore followed by lowercase letter. If not, I suggest a font change because you must be programming in Comic Sans MS or something. For example: __foo_Bar_foobar First two stand out.

It's not about recognizing. It's just that compilers have keywords / variables set that start with 1 or 2 underscores.

It stands out, but 2 underscores isn't as well recognizable as 1 underscore, if you get what I mean. It's hard at first to see how many they are (is it 1, 2, 3? The one below is one, this one looks like double so it must be 2 underscores...that is kind of the reasoning my brain uses...takes longer then other stuff).

Capitals in variables Is Like Writing With Capitals In Regular Text.

Hmm, one very peculiar rule I noticed:

"We do not use C++ exceptions. "

So, what's wrong with exceptions?

Quote:

Original post by Ed Welch Hmm, one very peculiar rule I noticed: "We do not use C++ exceptions. " So, what's wrong with exceptions?

If you expand the arrow on that entry, it'll tell you why that decision was made. (Linky)

Of the bigger annoyances in that guide are:
- The #define Guard
Tied to project/path/file. Sooner or later, things will get moved/renamed, and then one must fix them. This means that file operations require file editing, which means shell scripts doing this must edit the text as well, or risk losing uniqueness guarantee which results in obscure linker/compiler errors.

- All parameters passed by reference must be labeled const.
Makes std::swap impossible, as well as some other forms of [in/out] parameters. Makes sense with regard to C interoperability, but is still annoying.

- boost::call_traits are incompatible with previous requirement, yet allowed by guide. They do not guarantee that automatically selected type will not be non-const reference

- Start each file with a copyright notice, followed by a description of the contents of the file.
This is typically done by version control these days, so that copyright as well as potential changes in licenses can be managed centrally. Inserting it verbatim by end author requires boiler-plate copy-paste, as well as access to original license wording. This is considerable burden on developers, since from legal perspective, mis-typing or incorrectly pasting the text can make license invalid.

- Author Line
Same here. Should be based on version control system. No source has a single author. Requirement to manually add contributors duplicates (inaccurately) versions.

- Use TODO comments for code that is temporary
This is managed by third-party systems. Rather than adding TODO into source code, file an issue referencing the code. TODOs are notoriously left behind. Task is either resolved quickly, or it becomes driftwood. It's also likely that TODO will be resolved by someone else.

What I don't understand is that they apparently use stl containers but don't use exceptions. Either they have some special version of stl (similar to EASTL perhaps) or they just treat all exceptions as fatal errors. The latter makes a certain amount of sense for server-side stuff where the only "normal" exception would be out of memory... But either way you'd think they'd explain the apparent contradicton. It seems like a rather important point to know.

I know this doesn't add much to the discussion, but anyone else fondly remember way back to the time of yore when programming was fun and the_variable was the same as thevariable as theVariable? Remember when we could just sit down, write code and make the computer do stuff?

Ah... Those were the days...

Quote:

Original post by Anon Mike What I don't understand is that they apparently use stl containers but don't use exceptions. Either they have some special version of stl (similar to EASTL perhaps) or they just treat all exceptions as fatal errors.

For 360 stuff, Microsoft recommends use of the STL containers, but also recommends disabling exceptions in your project properties... Not sure what MSVC's STL containers behave like in this case, but it's interesting to note it's not just google...

OT: Knowing MS's tactics though, when I heard this, my first thought was that perhaps Sony's compiler doesn't cope with this as well as MS's and it's a form of vendor lock in ;)

Quote:

Original post by maspeir I know this doesn't add much to the discussion, but anyone else fondly remember way back to the time of yore when programming was fun and the_variable was the same as thevariable as theVariable?

You mean before you got a job as a programmer ;) ;P

Quote:

Original post by Anon Mike What I don't understand is that they apparently use stl containers but don't use exceptions. Either they have some special version of stl (similar to EASTL perhaps) or they just treat all exceptions as fatal errors. The latter makes a certain amount of sense for server-side stuff where the only "normal" exception would be out of memory... But either way you'd think they'd explain the apparent contradicton. It seems like a rather important point to know.

Let's see...

Quote:

From /usr/include/c++/4.5/bits/functexcept.h [...] // Helper for exception objects in void __throw_bad_alloc(void) __attribute__((__noreturn__)); // Helper for exception objects in void __throw_bad_cast(void) __attribute__((__noreturn__)); void __throw_bad_typeid(void) __attribute__((__noreturn__)); [...]

Quote:

From functexcept.cc #if __EXCEPTIONS [...] void __throw_bad_alloc(void) { throw bad_alloc(); } void __throw_bad_cast(void) { throw bad_cast(); } void __throw_bad_typeid(void) { throw bad_typeid(); } [...] #else [...] void __throw_bad_alloc(void) { abort(); } void __throw_bad_cast(void) { abort(); } void __throw_bad_typeid(void) { abort(); } [...] #endif

So that basically covers -fno-exceptions support in GCC; I have no idea how it's done in MSVC's STL.

Quote:

Original post by u Let's see... ... So that basically covers -fno-exceptions support in GCC; I have no idea how it's done in MSVC's STL.

So that falls into both categories actually. It's a special version of stl that internally treats all exceptions as fatal errors. I still think it warrants a mention in their guide...

MSVC (2010 express) doesn't appear to have any provision for non-throwing stl. If you turn exceptions off completely you get compile-time errors complaining about the use of exceptions with support turned off. I wouldn't be at all surprised if XBox had some customized version of the MSVC stl that lets them get away with it.

Quote:

Original post by Decrius Capitals in variables Is Like Writing With Capitals In Regular Text.

Nonsense. You have separators called spaces in "regular text".