If you really want to start learning OOP you should try to find a book on OOD (Development). I bought one called Design Patterns and its helped my understanding of OOD greatly.

///////////Class.h#ifndef __CLASS_H#define __CLASS_Hclass CClass{//...};#end if/////////////Class.cpp#include "stdafx.h"#include "Class.cpp"CClass::CClass(){}//.../////////////////SomeOtherClasses.cpp#include "stdafx.h"#include "Class.h"//never #include a .cpp

Add all your .cpp files to the project, and .h''s too if you want the ''intelisense'' to work.

Except under certain limited conditions I put each class in a seperate file. One exception would be classes that don''t do anything by themselves such as a root of a tree without the nodes and leaves. I also put each file in it''s own namespace just in case of name conflicts with other modules. If you don''t need you don''t have to use the scope resolution, but if there is a conflict it is easily added. I also keep functions down to a page to a page and a half. I group all similar functions together such as all constructors together, all I/O routines together, etc. One exception to that is a place the get and set routines together, i.e. rather than all get then all set I put a get and set for a single data member together. I also group those by how they are logically related. So routines that get and set location would be group together. I then group sets of those together such as location, scale and orientation. Overall I try to keep the distance in the code from one function to another a function of how closely they are related so I don''t have to scroll all over the place. I then put in eye catchers so I can easily spot the start of a section or function. I usually put a name on a section surrounded by comment lines of dashs and just a comment line of dashes on a function.

As far as comments go you use your judgement on what you might need or your teammates might need. If you have a section of code that is difficult to understand then you should examine it and try to understand why it is difficult to understand. That should lead to changes that you can make to make it more readable. An example is a set of calculations performed repeatedly with small variations. It can be hard to keep straight since the variation is small but significant. If you call a function instead then the variation is effectively large and apparent. You then only have to understand the calculation by itself and then how it is used, i.e. ah, I calculate the slope of this line and that line and use it in another calculation instead of (y2-y1)/(x2-y1) and (y4-y3)/(x4-x3) buried in some other calculation. Along the same lines I keep my code simple. It might be a calculation with 10 variables, but that doesn''t mean I have to do it on one line in one statement. I can do part of the calculation, assign it to an intermediate variable, and continue on and then do a final calculation with two or three variables instead of 10.

Clean, readable code is often at conflict with performance. Generally a small part of your code is performance critical. As a rule I expect 10% of my code to be at least 90% of my processing. Making the other 90% of the code ten times faster only saves me 9% of my overall processing. I would rather have it readable than faster. If I have to I will sacrifice readability for performance in the 10% of the code, but only after I know which 10% it is. Sacrificing readability even then is a last ditch effort. Once I''ve done everything I can to improve performance while keeping it readable would I consider sacrificing the readablity since a slow running program is better than one that doesn''t run at all.