string table_name; // OK - uses underscore.
string tablename; // OK - all lowercase.
string tableName; // Bad - mixed case.
Some questions on Google C++ Style Guide
Author
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
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.
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.
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_foobarFirst two stand out.
Author
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 nullsquaredQuote: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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
