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
C++: UpperCamelCase or lowerCamelCase?
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.
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]
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;
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*
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*
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.
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 EzbezQuote: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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
