# C++: UpperCamelCase or lowerCamelCase?

This topic is 3838 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Which do you prefer for method names? I'm getting ready to start writing a bunch of new code, and I can't decide which to use! So, I'm looking for a compelling reason to use one or the other. :) Thanks!

##### Share on other sites
I personally prefer upper camel case, but I don't really mind that much either way.

I'm usually fine with most standard naming conversions, with the possible exception of the one where classes are named in upper camel case with a leading C, such as CSomeClass. That C makes it extremely hard for me to parse the class name at a glance; if you want to use prefixes I prefer separating them out with an underscore like C_SomeClass instead.

##### Share on other sites
I use lol_underscores_lol case. But UpperCamelCase is next in terms of preference. I wouldn't wart it up, though. But class names are formal names, no? In English, this means Capitalization.

##### Share on other sites
I always follow the conventions of the standard library of which ever language I'm working in, leads to more consistent feeling code that way.

In C++ that means I use underscores but out of those two choices I prefer UpperCamelCase.

##### Share on other sites
I very much prefer UpperCamelCase for typenames, and lowerCamelCase for instances and method names.

##### Share on other sites
I like all_lower_with_underscores too, it's much easier to read.

As for UpperCamelCase vs. lowerCamelcase, I use both. At work we use UpperCamelCase for classes, structs, functions, and member variables (after the initial m_ and optional p (for pointers)).
lowerCamelCase is only used for auto variables.

It's a stupid system, but it's better than it was (same plus more warts).

##### Share on other sites
UpperCamelCase for methods and typenames, lowerCamelCase for private member variables and local variables.

##### Share on other sites
Worry about something important.

##### Share on other sites
What I use:

template < typename BaseClass >class some_basic_type{  void foo( BaseClass variable )  {    m_variable = variable;  }private:  BaseClass m_variable;};typedef some_basic_type<int> IntType;class ConcreteType{  void foo_bar( );}

Concrete types use camel case. Templated types use the STL style, since they get typedefed into CC.

This makes for conventient distinction, and makes use of template parameters look natural in the code.

##### Share on other sites
I am currently do it the ruby way (ClassName, method_name, variable_name)... I previously used .NET naming conventions.

##### Share on other sites
When I see lowerCamelCase on function names when the containing object definition's (ie, class\struct\etc) name is in UpperCamelCase or C, I feel like someone is dragging their nails across a blackboard (or green rather :P). Which is why I can't stand using java (well, one of the reasons).

I'm a .NET and C++ programmer, and I tend to keep with .NET's naming standards. The only time I will ever use LCC is when I'm naming method arguments or for a object's internal value for a property. However in C++, I don't tend to use properties (<3 MS specific) that much for member access.

I've also been known to mix it up in my C++ code by using C style naming for classes\struct\interfaces\etc along with a prefix as to what it is (ie "c_class", "t_template", "s_struct". etc). Namespaces however are still capitalized. For the object definition's members I stick with .NET conventions and strictly avoid "m_" prefixes. I can't stand those either :/

I know, I'm weird :-3

##### Share on other sites
Upper camel-casing is the most "annoying" to type but it's the one that looks better and that is easiest to read. Since I always use Visual Studio for C++, an IDE with excellent code-completion, I don't care for the "annoying to type" part so I gladly use it. I also use type prefixes for my variables and properties (ie: char szMyString[]) but I don't recommend it. It's a relic from all my years messing with the good ol' Win32 API that I just can't forget. [ignore]

For languages like Ruby that do not have any IDE with code completion, I prefer writing everything in lower-case, separating the words with underscores. I think that Java-style camel-casing looks bad aesthetically.

##### Share on other sites
Quote:
 Original post by kornman00using... a prefix as to what it is (ie "c_class", "t_template", "s_struct". etc). ... and strictly avoid "m_" prefixes. I can't stand those either :/

Don't you think that's a little, well, inconsistent?

##### Share on other sites
I prefer to have class/struct names to be upper case (i.e. ObjectFactory) and functions to be in lower case (getSomeObjectFactoryYeh ()). I don't like the C* or S* prefix on classes and structs. It's just ugly.

I also use m_ and g_ (where applicable) for member variables and global variables. Local variables i don't prefix.

[using fonts in a renderer as a random example]
class Font;class FontManager;struct FontInfo;enum FontType;int getFontSize (int scr_height, int points);class FontManager{private:   Renderer * m_Renderer;public:    Font * createFont (const char * face, ...);};int g_BadGlobalVariable;

##### Share on other sites
UpperCamelCase for everything except [member] variables, which get lower_case_underscores. I stopped using Hungarian notation when I got good enough at programming to not have huge multi-page functions/methods - if the variable declaration is right there in front of you and the type pops up when you hover your mouse over it, you don't need to mangle the name. :P

Member and global variables still always get m_ and g_ respectively, and static variables get s_ although they're kinda hackish so I try and stay away.

...good god I miss real coding, I've been stuck using ColdFusion for the last six months. *shudder*

##### Share on other sites
class class_name{public:    int method_name()    {        int local_variable = 0;    }private:    int m_private_variable;};

This is a new scheme by me. I used to avoid m_ like the plague, writing mPrivateVariable instead, but then my Shift key broke a while ago, and in the time between buying a new keyboard I wrote code like that. And writing libraries with the same style as the SCL and Boost makes me feel like an elitist coder, which gives me a warm feeling. [grin]

Edit: New scheme for me. Just clarifyin', is all.

##### Share on other sites
Quote:
 Original post by DeyjaWorry about something important.

Damn right. I've seen coding standards that went into the minutiae of function/class/variable naming so that 'paiFooBar' was totally valid. Of course, 'paiFooBar' is utterly useless as a name as it doesn't actually tell you what its purpose is, 'pressure_torque_graph_data' is far better.

Find a style you are happy with and stick with it. Your coding style will become a sort of signiture in effect. I'm working in a large project at the moment with several software engineers and I can tell who wrote a piece of code from the way it's formatted and the naming style.

Skizz

##### Share on other sites
Quote:
 Original post by SkizzFind a style you are happy with and stick with it. Your coding style will become a sort of signiture in effect. I'm working in a large project at the moment with several software engineers and I can tell who wrote a piece of code from the way it's formatted and the naming style.

I'm going to have to disagree with this. (Note: I've only worked on one programming project with multiple people, and we were all amateurs) Having multiple different coding styles in a single program is just plain annoying. When you can remember whether it's "FooBar" or "Foo_Bar" or "foo_bar" or anything else, you have to look it up even though you know that it's some variant of "FooBar".

More annoying was the placement of brackets. Each person was doing that a different way which almost makes tabbing pointless. There'd be large two-tab gaps between some levels simply because of the inconsistency of the brackets and tabbing. It increased the time spent in reading code noticeably.

Consistency of choice is better than any specific choice.

##### Share on other sites
Quote:
Original post by Ezbez
Quote:
 Original post by SkizzFind a style you are happy with and stick with it. Your coding style will become a sort of signiture in effect. I'm working in a large project at the moment with several software engineers and I can tell who wrote a piece of code from the way it's formatted and the naming style.

I'm going to have to disagree with this. (Note: I've only worked on one programming project with multiple people, and we were all amateurs) Having multiple different coding styles in a single program is just plain annoying. When you can remember whether it's "FooBar" or "Foo_Bar" or "foo_bar" or anything else, you have to look it up even though you know that it's some variant of "FooBar".

Autocomplete helps with the FooBar / Foo_Bar / foo_bar issue, and if you set up the source code right the autocomplete prompt can give extra info. Also, if you use several third party libraries then consistancy of naming styles goes out the window. Heck, even Win32 is inconsistant - MostFunctionsAreUppercaseCamel (like CreateWindow) but some are lowercaseCamel (like mmioOpen).

Quote:
 More annoying was the placement of brackets. Each person was doing that a different way which almost makes tabbing pointless. There'd be large two-tab gaps between some levels simply because of the inconsistency of the brackets and tabbing. It increased the time spent in reading code noticeably.

Brackets and tabs are whole different ball game.

Skizz

##### Share on other sites
Quote:
 Original post by EzbezHaving multiple different coding styles in a single program is just plain annoying. When you can remember whether it's "FooBar" or "Foo_Bar" or "foo_bar" or anything else, you have to look it up even though you know that it's some variant of "FooBar".

That's why we have Intellisense. [wink]

As for my own standards, I perfer lowerCamelCase for method names, UpperCase for class names, and I have all my braces on seperate lines, with a tab after each opening brace.

##### Share on other sites
Just thought I'd weigh in on the brackets and tabs stuff. I'm a firm believer that brackets and for, if, else, while, etc statements should get their own line. I'm still on the fence about whether or not a single statement after a for, if, while, etc should have brackets around it, but I generally lean towards yes just for 1) consistency, and 2) I find usually when coding I end up going back an adding more statements and adding brackets anyway. Though, if someone else omits them around single lines, I find it just as readable.

Compare:
while(1) {   if(booleanValue) callFunction();   if(anotherValue) {      callFunction2();      while(value) {         doSomething();      }   } else {      callAnotherFunction();   }}

with
while(1) {   if(booleanValue)    {      callFunction();   }   if(anotherValue)   {      callFunction2();      while(value)      {         doSomething();      }   }   else   {      callAnotherFunction();   }}

Sure, the first one is shorter, but you can't tell me its easier to read.

##### Share on other sites
Quote:
 Original post by Matt328Just thought I'd weigh in on the brackets and tabs stuff. I'm a firm believer that brackets and for, if, else, while, etc statements should get their own line. I'm still on the fence about whether or not a single statement after a for, if, while, etc should have brackets around it, but I generally lean towards yes just for 1) consistency, and 2) I find usually when coding I end up going back an adding more statements and adding brackets anyway. Though, if someone else omits them around single lines, I find it just as readable.Compare:*** Source Snippet Removed ***with*** Source Snippet Removed ***Sure, the first one is shorter, but you can't tell me its easier to read.

I too use the latter layout. I think the first layout was used by K&R because all they had were 80x25 character displays and it allowed for more code to be viewed at the same time (GUI's were the stuff of research labs). These days, 140x50 character edit windows are normal these days so you can sacrifice a few lines for improved readability.

I always bracket statements after for, if, else and while:
if (expr)  statement1;  statement2;

or worse:
if (expr)  statement1; statement2;

and
if (expr)  statement1, statement2;

are different. A bit forced I agree, but being in the habit of always putting in the braces it just can't happen in my code.

Skizz

##### Share on other sites
Quote:
 I always bracket statements after for, if, else and while:

You forgot one (I've actually seen people do this one but have never seen people do the ones you mentioned for some reason)
if (cond1)    if (cond2)        statement1;else    statement2;

##### Share on other sites
There are lots of ways to confuse anyone reading the code:
  while (expr)  {     statements;  } while (expr);  for (i = 0 ; i < 10 ; ++i);  {    statements;  }

Skizz

##### Share on other sites
Quote:
 There are lots of ways to confuse anyone reading the code:

But how do those relate to lack of braces? The examples you gave were of logic errors that can occur because of not specifying additional braces and hence I gave another example of the same type of error not of some random and unrelated type of error.

The code with braces is equivalently to:
if (cond1){    if (cond2)    {        statement1;    }    else    {        statement2;    }}

However it is obvious that the intent was:
if (cond1){    if (cond2)    {        statement1;    }}else{    statement2;}

##### Share on other sites

This topic is 3838 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## 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