Sign in to follow this  
Giedrius

Some questions on Google C++ Style Guide

Recommended Posts

Giedrius    164
Google C++ style Guide I hate how a lot of coding conventions don't explain or provide any argumentation on its choices and why is it preferred over other conventions. Variable Names
string table_name;  // OK - uses underscore.
string tablename;   // OK - all lowercase.
string tableName;   // Bad - mixed case.


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. 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).
Function Names 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.

Share this post


Link to post
Share on other sites
Antheus    2409
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.

Share this post


Link to post
Share on other sites
rip-off    10976
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.

Share this post


Link to post
Share on other sites
nullsquared    126
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.

Share this post


Link to post
Share on other sites
Antheus    2409
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.

Share this post


Link to post
Share on other sites
nullsquared    126
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.

Share this post


Link to post
Share on other sites
Decrius    100
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.

Share this post


Link to post
Share on other sites
Drew_Benton    1861
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)

Share this post


Link to post
Share on other sites
Antheus    2409
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.

Share this post


Link to post
Share on other sites
Anon Mike    1098
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.

Share this post


Link to post
Share on other sites
MarkS    180
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...

Share this post


Link to post
Share on other sites
Hodgman    51234
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

Share this post


Link to post
Share on other sites
u    211
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 <new>
void
__throw_bad_alloc(void) __attribute__((__noreturn__));

// Helper for exception objects in <typeinfo>
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.

Share this post


Link to post
Share on other sites
Anon Mike    1098
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.

Share this post


Link to post
Share on other sites
jamby    147
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".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this