C++: UpperCamelCase or lowerCamelCase?

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.

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.

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.

I very much prefer UpperCamelCase for typenames, and lowerCamelCase for instances and method names.

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

UpperCamelCase for methods and typenames, lowerCamelCase for private member variables and local variables.

Worry about something important.

What I use:



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.

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

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

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.

Quote:

Original post by kornman00 using... 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?

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]

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*

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.

Quote:

Original post by Deyja Worry 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

Quote:

Original post by Skizz 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.

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.

Quote:

Original post by Ezbez Quote: Original post by Skizz 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. 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

Quote:

Original post by Ezbez 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".

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.