Organizing the Source Code

Each source and header file should have a consistent layout; it makes finding and managing the code much easier. The way you access portions of your program should also be consistent.

Always use public, private, and protected specifiers; don't rely on the defaults. List the public members first, then protected ones and finally the private ones. List the data members in a group after the methods. This is trickier when using classes built by the Microsoft Wizards, but it is worth the time to rearrange these files and get it right.

Line up function return values, names and parameters. Consider these two listings; which do you find easier to read?

bool GetStartFromEnd (CTime& start, CTime end, int nSizeOfList, int nAudioDuration);
int GetWhichList (CCaller* pCaller, CString customerID, bool onlyOne);
void GetWhenToCall (CCaller* pCaller, CString customerID, bool& alwaysNow, CTime& start, CTime& end, bool& useTimeZones, int& whichTilt, int& nIsCrisis);
void GetStartTime (CCaller* pCaller, CString customerID, CTime& start,CTime& end);
void GetEndTime (CCaller* pCaller, CString customerID, CTime& start,CTime& end);
bool  GetStartFromEnd (CTime& start, CTime end, int nSizeOfList,
int   GetWhichList    (CCaller* pCaller, CString customerID, bool onlyOne);
void  GetWhenToCall   (CCaller* pCaller, CString customerID,
                       bool& alwaysNow, CTime& start,
                       CTime& end, bool& useTimeZones,
                       int& whichTilt, int& nIsCrisis);
                       int nAudioDuration);
void  GetStartTime    (CCaller* pCaller, CString customerID, CTime& start,
                       CTime& end);
void  GetEndTime      (CCaller* pCaller, CString customerID, CTime& start,
                       CTime& end);

Put the constructor(s) first in the appropriate section, followed by the destructor. Alphabetize the rest of the methods, both in the header file and in the implementation file. Or, rather than alphabetizing, consider grouping your methods by sets of functionality. This gives you a quick view of what your objects do, and is a good check on whether you are asking any one object to do too much.

Alphabetize the #include directives at the top of your implementation files (be careful about order dependencies, but to the extent that they are under your control, consider an order dependency to be a bug, and fix it). Comment each #include statement if it isn't obvious why you needed it. And be sure that every header file has inclusion guards to protect against multiple includes.

© 1998 by Wrox Press. All rights reserved.