Back to General and Gameplay Programming

C++ notation and naming conventions

Cybertron · 2002-08-02T06:48:57

I am working on a new graphics interface right now using OOP, and was wondering what are the standard naming conventions for classes, variables, functions and enums I already use hungarian notation for variable names (except for ''m_'' or ''g_'') but classes are all over the place and functions are usually just describe what they do In need your input on a logical way to orginize all these data types and structures

General and Gameplay Programming Programming

Started by Cybertron July 29, 2002 08:59 PM

48 comments, last by Cybertron 21 years, 8 months ago

Dean Harding

546

August 01, 2002 06:53 AM

quote:Original post by Cybertron
now watch everything go 64bit and make ''lp'' incorrect!

Too late! "lp" is a left-over from 16-bit, segmented days, where the "l" meant a FAR (or LONG) pointer.

If I had my way, I''d have all of you shot!

codeka.com - Just click it.

civguy

308

August 01, 2002 08:44 AM

I use the Java naming convention:

class names : MyClass
method/function names : myMethod()
constants : MY_CONSTANT
member variables : _myMemberVariable (underscore helps the autocomplete tool and clarifies sometimes)
variable names : myVariable

Reversed from what davepermen uses

I don't use global variables. Hungarian notation is just useless burden. Variable's type should be apparent from what it is, or knowing its type should be unnecessary for the programmer.

And rather off-topic, if I need to add a comment (ok this is a bad example since it's so simple):

  //doblah for all elementsfor (int i=0;i<_numberOfElements;i++) {  doblah(element[i]);}

I'll rather do a new function, which doesn't need any comments

        doblahForAllElements();

Commenting = bad solution in general
Refactoring and long variable/method names = good

(damn buggy source tags by the way)

[edited by - civguy on August 1, 2002 9:54:52 AM]

civguy

308

August 01, 2002 09:04 AM

Oh yea, there's one type of commenting I like: commenting what a whole method or a class does. Even if a method mostly consists of calls to straightforward method names (doThis(), doThat()), it's good to tell what it's ultimate purpose is (in case the method/class/argument names don't tell enough)

[edited by - civguy on August 1, 2002 4:33:47 PM]

Sneftel

1,788

August 01, 2002 10:01 AM

quote:Original post by Magmai Kai Holmlor
That implies that xValue is a static member

No, it doesn''t. Remember that :: is the scope resolution operator. In this case, it tells the compiler that the xValue you''re referring to is the one declared in the scope of ClassName. So that''s the one it uses.

The fact that :: is often used to refer to static members merely stems from the fact that scope resolution is more often useful to refer to variables in non-searched scopes, than to access overridden identifiers, such as here.

Don''t listen to me. I''ve had too much coffee.

Arild Fines

968

August 01, 2002 04:06 PM

quote:Original post by Sneftel
No, it doesn''t. Remember that :: is the scope resolution operator. In this case, it tells the compiler that the xValue you''re referring to is the one declared in the scope of ClassName. So that''s the one it uses.

He said ''implies'' - and to 90% of the people reading it, it does look like you are accessing a static member variable. this->variable is far clearer.

--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]

Shannon Barber

1,684

August 01, 2002 04:41 PM

quote:Original post by Sneftel
In this case, it tells the compiler that the xValue you''re referring to is the one declared in the scope of ClassName. So that''s the one it uses.

Your syntax is obviously correct, I was pointing out that use ''this->var'' leaves no ambiguity as to the scope of the variable (must be a member), whereas ClassName:: does leave some ambiguity. It could either be static or non-static member. By using this-> to denote non-static''s, you can use ClassName:: to denote statics, to remove the ambiguity by convention and within the syntax of the language.

quote:Origin
Don''t go crazy with prefixes. A g_lpaszMsg variable doesn''t tell you anything. Instead, come up with good descriptive names for your variables.

That tells me it''s a global long-pointer to an ansi string, terminated with a zero, and it''s a message.

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Zipster

2,420

August 01, 2002 05:03 PM

quote:That tells me it''s a global long-pointer to an ansi string, terminated with a zero, and it''s a message.

I think he meant that it doesn''t tell you what it''s used for. Not that the prefixes are supposed to do that, but the point is not to go overboard with the prefixes if you aren''t going to name the variable so it''s indicative of its purpose anyway.

Cybertron

122

Author

August 01, 2002 06:49 PM

Thats interesting, tons of prefixes can tell you what it is when READING, but makes it slower to WRITE

Hungarian notation is alos good when you don''t want to name it anything! instead of something like ''iIndex'' I just use ''i'' for loops!

I think that Anonymous guy should register...