23.4 Naming conventions

The naming conventions in MFC programs are that the MFC class names all start with a capital C , and the class member functions are all written as run-together phrases in which each word is capitalized. FillSolidRect is an example of such a function name .

We're free to give our variables any kinds of names we want, but since MFC programs are so big and cumbersome, we try and make the names as helpful as possible. A good variable name will give you (a) information about the type of the class the variable is an instance of, and (b) information about the meaning of your variable inside the program. A common convention is to give our variables names which start with some letters to remind us of the type of the variable, and to have the rest say something about what the variable does. A variable name should always start with a lower-case letter. If you like you can mix in some capitals later into the name, to indicate word breaks, as in bSoundFlag , for a BOOL variable. But all lower case for the variable names is easier to remember and faster to type.

Thus, we might give a CString variable the name cstrhello . Or we could use the names cstring_hello or cStrHello . In the cases where a variable is a pointer to a class, we like to start the variable name with a p . Thus a CDC* variable might be named pdc or perhaps pDC .

What about variables that are examples of general types rather than classes? It's common to use n as the prefix to indicate an integer variable. Sometimes, when an integer is a 'count' variable used to count something like the number of pixels in the screen's width, the c prefix is used. The letters f or b signal a variable which is a BOOL flag. As just mentioned, the letter p signals a pointer. The older Windows documentation sometimes raises the (no longer meaningful) distinction between a normal pointer type p and a 'long' or 'far' pointer lp . Win32 programming often uses a kind of pointer-like index object called a HANDLE , and the h prefix is used for variables of this type. In older Windows code we often see the prefix sz or lpsz to stand for a variable which represents a string of characters . Of course in MFC programming we will generally use CString variables instead.

You'll notice a bit of ambiguity in all this; the truth is that all of our naming conventions are a little flexible. The golden rule is to develop a few good conventions and stick to them in all of your code. As you learn more about programming, however, your ideas about the conventions will evolve , so don't feel duty-bound to forever stick to something dumb that you used to do when you were starting out.

Windows uses a lot of constants that are defined in its header files. These are always written in all capitals, with underscores separating the component parts . Often a defined constant has a prefix that reminds you of the context in which the constant is used. As a random example, the DT_CENTER and DT_VCENTER constants that can be used as arguments to the CDC::DrawText method have the DT prefix to remind you that these constants have to do with the DrawText .

As a rule you should never use one-letter names like u or x , unless it's immediately obvious what you mean, nor should you use meaningless names like foo or whatever . The one and only time it's definitely acceptable to use one-letter variable names is for the indices i, j, k used to index loops .

The AFX part of the MFC programming picture has to do with what's in those 30 or so files that the Visual Studio AppWizard creates for you when you make a new project. One thing worth mentioning here is that MFC has a few global functions with the prefix Afx . These functions are used for getting information about your program. An example of such a function is CWnd* AfxGetMainWnd( ); . We'll look some more at AFX below. But first we'll have a little information for Win32 programmers, some information about documents and views, and another look at the Pop program code.

Later we'll also define a lot of classes of our own. To make clear that these are our classes, we'll start all their names with a lower-case c . Thus we will use a name like cMyClass rather than MyClass . We would absolutely never want to use a name like CMyClass , as that last format should be left only for use by MFC. The MFC class members generally start with m_ , although the CPoint class members are just called x and y and the CRect members are left , top , right , and bottom . We'll always have our own class data members start with an underscore _. A general principle of naming members of your classes is to start the member names with an underscore, and then you have the possibility of using the name without the underscore as an accessor function name (although usually it's a better practice to start accessors with the word 'get'). It's a good idea to give your class's private or protected members 'ugly' names (by starting them with an underscore ) to remind you that they are indeed not public.

When we define a special function as one of our class methods , we almost always use the convention of starting it with a lower-case letter and using capital letters at word breaks. Thus, we might have a randomInt method or a setAutoRotate method. You never want to start your methods with a capital letter because then they'll look like standard MFC functions, and next programmer to use your code will get confused when he or she tries to look up MFC documentation for these functions.