C and C++ standards started before Microsoft and a lot of conventions where created UNIX system such as Solaris used strStringName as a standard to define type and name Microsoft used m_MemberName to define members of an object Some other used Camel notation, Hungarian notation (Microsoft mainly) and loads of other conventions. Why so many? Show 2 people the same object and they think different things, well whatever notation you use is less important than site consistency. Most software is developed by teams of analysts and programmer working together, over time the team sheet changes and to allow for change a site convention is used. Of course any new member will learn the site conventions quicker, if the site uses a generally accepted convention such as that employed by Microsoft or Sun. In team development consistency of approach is paramount otherwise it very quickly becomes a Wild West show. NOTATION In object orientated programming we often have objects containing other objects, so to tell if the programmer is using an object or a method of an object we use notation to clarify the situation (make the code more readable). Separation of Logic Best practice for coding suggests that the presentation, business logic layer and storage layer should be separate. What that should give is independent presentation so changes to a screen should not affect the business layer and changes to storage layer should not affect the business logic. Many programmers do not take the time to separate out their design, for small applications this is sometimes can be good approach with regard to time and maintenance, however in lager applications not clearly defining boundaries can be a disaster. Creating your own wrapper class around presentation, business and storage layers can improve maintance of code and scalability of an application. In small scale application this is rarely a problem, however good practice is always good practice no matter what programming language or methodogly is used. Basically make your system changeable and separate out the logical components of your system. No C++ application should be made as non portable. If you use wrapper around you presentation class then if MFC changes or you are asked to port the code to another platform, the task becomes easier and the same applies to business logic (process behavior) plus persistence logic (storage). Factory Patterns Or how to make a program unreadable! Factory pattern is a very useful pattern when used correctly, however overuse