• Advertisement

Archived

This topic is now archived and is closed to further replies.

Cdong Standards.

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is it best to name my classes like: myClass, or theClass, or aClass. How do the windows game programming gurus do it?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Every variable should be my*something*. I love grading student code that is my this and that, it rules.

Share this post


Link to post
Share on other sites
quote:
Original post by timm
How do the windows game programming gurus do it?


I don''t think LaMonthe does C++, so he wouldn''t have any class names.

You should the naming scheme that matches what you are coding. If you''re working with/making extentions for the STL, everything should be lowercase_and_have_underscores; if you''re doing m_mfcProgramming, you should use scope warts and camelCase. If you''re doing ICOMInterface programming, then CConcreteClasses should be used.

The only place I have ever seen mySomething used is in textbooks or maybe articles as rhetorical examples of where you put your class declaration.

Recently I was convinced that explicitly stating the C++ scope access was better than using scope warts, and after trying it I like it better:
this->member_variable (instead of m_member_variable)
Class::static_property_or_method
::global
local


Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ ]

Shamelessly ripped from Oluseyi

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
You should the naming scheme that matches what you are coding. If you''re working with/making extentions for the STL, everything should be lowercase_and_have_underscores; if you''re doing m_mfcProgramming, you should use scope warts and camelCase. If you''re doing ICOMInterface programming, then CConcreteClasses should be used.



And what if your program uses STL, MFC, COM, and other libraries at the same time? With all those mixed naming conventions used right next to each other it''s going to get very confusing, IMO.

I dunno, right now I''m still of the opinion of writing wrapper classes (using composition) for all external library classes.

Doing this lets you use one naming convention throughout your program, allows you to add free extra functionality to each wrapper class without affecting your program, and allows you to even switch library implementations behind the scenes without affecting code already written.

Still, it sucks to rewrite all the public functions for every class you use, but I still feel this is the best way to go about it.

As for my, a, the, I use scope warts instead. I''m undecided on explicitely stating the C++ scope access as Magmai is doing. It''s a lot more typing, but it is easier to read I guess... gotta think more about this


- Houdini

Share this post


Link to post
Share on other sites
It doesn''t matter what your naming scheme is so much as that you use it consistently.

I personally detest the *my* is myWhatever. Other people like it. It doesn''t matter a whole lot really.

-Mike

Share this post


Link to post
Share on other sites
I like the my for class member because it gives a prefix to member variable and I find it easier to read than m_.

Seems like my brain has trouble to read underscores and slows me down a lot, so with my, stuff is more fluent.

Share this post


Link to post
Share on other sites
I agree with Magmai to an extent. All my class members and local variables use MixedCase, and I write class names like CVector or CPlayer. I rarely use global variables, but when I do, especially within classes, they are prefixed with a global scope resolver ::LikeThis. I find that having a single convention of case and spacing across all constructs (Functions, VariableNames, etc) helps me; it just looks pretty.
I don''t like myMemberName, because camel casing is really distracting, especially when I have more than one word in the identifier name, like myGunName. Ugly. I use naked pointers instead of std::vector for everything that needs to be in an array, and array names are usually ended with "List," as in EntityList. The only other indicator of type that I use is for some boolean values, which are prefixed by "Is," as in IsAlive.

That''s just about everything about my wacky coding style.

Peace,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

[if you have a link proposal, email me.]

Share this post


Link to post
Share on other sites
quote:
Original post by timm
How do the windows game programming gurus do it?

However it damn well pleases them, of course! Seriously, though, if you are working on your own project then choose something you like and be consistent about it. If you are working on someone else''s project, chances are it''s not your problem. The only thing to beware of is that a coding standard should not restrict expressivity - i.e. it should only contain stylistic guidelines.


[C++ FAQ Lite | ACCU | Boost | Stroustrup on Learning C++]

Share this post


Link to post
Share on other sites
The way I do things is by putting "m_" before the variable name.
for instance:

class CExample
{
public:
float m_fFloatNumber;
};

I see most people do this, however this is just from my experience. using "my" is kind of used for beginners as they grasp ownership concepts in using classes.

Share this post


Link to post
Share on other sites
quote:
Original post by Gorg
I like the my for class member because it gives a prefix to member variable and I find it easier to read than m_.

Seems like my brain has trouble to read underscores and slows me down a lot, so with my, stuff is more fluent.


Being the company''s coding standard doesnt hurt either.


University is a fountain of knowledge, and students go there to drink.

Share this post


Link to post
Share on other sites
my is ok, probably alot easier then using underscores. i hate makeing variables with underscores, it just slows me dwon.

Share this post


Link to post
Share on other sites
Why not just call the classes what they refer to and then just stick the whole lot in your own namespace, so you don''t need to worry about it. My students have been known to use every solution but this one, and some of the results are quite unintelligible. Sticking C in front of everything just makes you think you''re writing an MFC app

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I use the Java naming convention in C++. Classes start with capitals, functions and variables start with lower case e.g.

Player player;
World world;
world.add(player);

Its easy on the eye and looks much nicer than CPlayer/CWorld/CClass.

By the way, I think the idea of writing wrappers for all external libraries you use isn''t very well thought out. For the small readability increase you get, you pay for in writing vast quantities of wrapper code.

What if someone writes a class with 100 weird named method names? Are you going to write a new class wrapper with 100 forwarding methods?

Share this post


Link to post
Share on other sites
quote:
Original post by gregs
Sticking C in front of everything just makes you think you''re writing an MFC app


Not for me, due to the fact that I wouldn''t touch MFC with a 10-foot pole (especially not to integrate it into a game or other high-performance program).

Peace,
ZE.



//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

[if you have a link proposal, email me.]

Share this post


Link to post
Share on other sites
Sticking C in front tells you it's a Concrete class, as opposed to a pure abstract one, a.k.a. an Interface. So if they're actually doing OOP the C's & I's tell you something. If they're doing some quasi-OO C++ exercise, and only have C's, then they don't mean anything.

quote:

Why not just call the classes what they refer to and then just stick the whole lot in your own namespace

I thought namespaces were friggin' great, and I use them all the time. I think newbies are under the impression namespaces are (only) for people writing libraries.

quote:

And what if your program uses STL, MFC, COM, and other libraries at the same time? With all those mixed naming conventions used right next to each other it's going to get very confusing, IMO.


Whatever ignites your reactor, but I'm actually starting to like the mixed notation, because it tells you what library the stuff you're working on comes from.

I'm also starting to favor all lower case, because I hate hitting the shift-key all the time.

[edited by - Magmai Kai Holmlor on April 21, 2002 2:08:29 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Big B
[quote]Original post by Gorg
I like the my for class member because it gives a prefix to member variable and I find it easier to read than m_.

Seems like my brain has trouble to read underscores and slows me down a lot, so with my, stuff is more fluent.


Being the company''s coding standard doesnt hurt either.


University is a fountain of knowledge, and students go there to drink.

Yeah, but I am not working there anymore. But I still use it anyhow.

Share this post


Link to post
Share on other sites
I use these:

CVendingMachine // regular class
IGraphicEngine // abstract class
EInvalidResolution // exception class
large_wooden_statue // variable
find_target // function

It is a lot of underscores, but I use the dvorak keyboard layout, so they don''t slow me down.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
By the way, I think the idea of writing wrappers for all external libraries you use isn''t very well thought out. For the small readability increase you get, you pay for in writing vast quantities of wrapper code.



If you had read my post you would have seen that writing wrapper classes aren''t just for a "small readability increase". Here are a few more reasons for doing it...

It makes it easier to write since you don''t have to remember 10 totally different naming conventions if you use 10 external libraries.

It allows you to add extra functionality to an existing application without having to write a new derived class then editing all your all previous code to use this new class.

It allows you to group multiple functions into one "easy to use" function. Anyone who''s programmed in Direct3D knows what I mean (ie, one Initialize() function).

It allows you to add your own custom error handling to every library. Want to automatically write all errors to a log file? No problem, just include that in the wrapper class. Do you use exceptions but a particular library doesn''t? No problem, just include them in the wrapper class.

It lets you switch library implementations whenever you want. Imagine you are halfway through writing an application that does a lot of image manipulation. You just now realize that the current image library you are using is too slow. It sure would be nice to be able to quickly plug in different image libraries to see which is fastest with your app. Good thing you used a wrapper class. One file change and your whole app now uses FreeImage, or DevIL, or LibPNG, or you name it. Much easier than hunting through hundereds of thousands of lines of code for all function function calls and class declarations of your image library and renaming those to a new library''s class/function names.

Or you could have finished an OpenGL game but everyone now wants a DirectX version. Whew, good thing you put OpenGL in a wrapper class, because porting your app to DirectX is now fairly trivial.

3rd party libraries will invariably contain bugs, and if the library isn''t open source you can''t fix em. Although you may remember which function to stay away from others working on the application may not and could use that function which may cause a hard to find bug. Had you written a wrapper class you could left that function out, or made it private.


quote:
Original post by Anonymous Poster
What if someone writes a class with 100 weird named method names? Are you going to write a new class wrapper with 100 forwarding methods?



Ah, I knew I had forgotten quite a few more reasons to use wrapper classes. Thanks for the reminders .

If you using a class that contains 100 public methods then odds are half of those should be private, you will never be using most of those functions, or that class needs to be broken down into smaller classes. In any of these three scenerios you could write a wrapper class(es) that makes this class much easier to read and use (ie, you don''t need to look through 100 function definitions just to find the one you are looking for).

Also, if all those 100 methods are all "weird named" then what better reason to wrap it so you can use more natural easy to remember function names. I mean, do you seriously want to keep looking through 100 methods in the class everytime you want to call a function because you can''t remember the weird names they give their functions?


So in closing, and IMO, the only thing that "isn''t very well thought out" was your argument for not using wrapper classes. No offense intended.


- Houdini

Share this post


Link to post
Share on other sites
Hi,

I use java naming convention for class names, Interfaces are names in "-able" or "-Interface"

And recently I wrapped all my reusable code in namespaces so that I can use it with nehe basecode.

And finally, I am the only one that read my code... so I do what I want.

About wrapper classes, I use such way to write once a tedious piece of code (e.g. : initialize DirectInput) so that performing usual operations need only one call that is understandable instead of a bunch of lines of horrible code.


----
David Sporn AKA Sporniket

Share this post


Link to post
Share on other sites
No standard here.. for classes. I do for others, enum, structs, typedefs, #defines. Usually I will cap the first letter of a class. .. nothing important.

How many people use the "Pre/Postcondition & return" method for commenting?

/*
precondition:
postcondition: does this, blah that
return: true because it wants to!
*/
bool waste(){}


I don''t really care for it, but I''ve seen it in some books, and had a prof who REQUIRED it be used.

~ me ~

Share this post


Link to post
Share on other sites
one problem with the my___ variables is sometimes you get bad variables.

For one game we had things like:
myBalls->Scratch();


So watch out!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
coreect speeling :>

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Houdini
So in closing, and IMO, the only thing that "isn''t very well thought out" was your argument for not using wrapper classes. No offense intended.

- Houdini



No offense intended from me either

I just mean that I am not going to rewrite the standard C++ library just because it doesn''t follow the same naming conventions. It would just require too much work for little gain. I don''t find have different naming conventions that big a deal. If I am using lots of functions, I can''t remember what most of them are called regardless of the naming convention; I have to look them up.

However, I would write wrapper classes for things like Direct3D, but that is only because the interface is inadequent for productive use. I do write wrapper classes for various reasons but I would never write wrapper classes for everything. It just isn''t productive, in my opinion.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
I just mean that I am not going to rewrite the standard C++ library just because it doesn''t follow the same naming conventions.



Like I said, it wouldn''t be just because it doesn''t follow the same naming convention. I also I wouldn''t necessarily recommend writing wrapper classes for the whole STL either. But I''ve actually written wrapper classes around the STL containers because:

A) They have confusing function names. IE, does empty() empty the container or check if it''s empty? Does clear() clear the container or check if it''s clear?

To remove an item at a specified index you use erase(), but to remove an item from the end you use pop_back(). Why not erase() and erase_back()?

The fact that I like to reserve the name "vector" for my math library. Not that I''m worried about name conflicts (that''s what namespaces are for) but you need to look at code before you know if a variable named Vector truely is.

B) I''ve added functionality to them, like specifying whether I want the container to automatically call delete on an items it erases.

C) I extend the STL extensively by writing STL compliant containers all the time (directory iterator, string token iterators, database containers, etc) so it''s nice to be able to use the same naming convention as the rest of my custom classes.

quote:
Original post by Anonymous Poster
It would just require too much work for little gain.



True, it does take a lot more effort in the beginning, but I''ve found it''s save me a lot of time later, and it''s just plain easier to work with for me.

I guess the same could be said for documenting code, or for writing technical specifications and flowcharts. Some people think the extra time spent saves them time later on, some people don''t.

quote:
Original post by Anonymous Poster
I don''t find have different naming conventions that big a deal. If I am using lots of functions, I can''t remember what most of them are called regardless of the naming convention; I have to look them up.



That''s true. I also find myself looking up function names quite a bit. But I''ve also found that if I use function names that I find most natural, I can usually "guess" at the name and get it right. For instance, for any class that deletes/erases/removes an item my function name would be DeleteX() where X is the name of the item. I don''t have to check if it''s delete_x(), deletex(), deleteX(), DeleteX(), DELETE_X(), remove_x(), removex(), removeX(), RemoveX(), REMOVE_X(), erase_x(), erasex(), eraseX(), EraseX(), or ERASE_X().

Ok, ok, so that example is a bit contrived, but I hope you get my point .

quote:
Original post by Anonymous Poster
However, I would write wrapper classes for things like Direct3D, but that is only because the interface is inadequent for productive use. I do write wrapper classes for various reasons but I would never write wrapper classes for everything. It just isn''t productive, in my opinion.



Well, like I said in my first post, I''m not saying that writing wrapper classes for everything is definately the best choice, but I''ve found it very helpful for me. And the extra work spent now could possibly save me a lot of time in the future.


- Houdini



Share this post


Link to post
Share on other sites

  • Advertisement