1001 Tips for Better Programming

Here are 1001 tips to writing better programs. Some are commonly agreed mistakes that novice programmers make, other are 'pet peeves' I have developped. Nevertheless, going through the list and thinking about each issue should make you a better programmer, even if you choose not take my advice (Heck, even I don't take my own advice all the time, why should I expect you!)

Yes, I know, we are not at 1001 yet, but getting there slowly...

Tips / Mistakes / Pet Peeves

1. Use 'const int' instead of #define

   #define is a processor directive. It is not meant to be used to define constants. A good compiler, and most compilers are clever these days, will have the same optimisations for 'const int' that is possible for define. On top of that, the compiler will give you good warnings and allow you to debug your code if you use 'const int' rather than #define.

   You should only use #define if you are trying to communicate something to the pre-processor, such as 'hey, this file is included already, don't include it again', or to say 'hey, load this file under WIN32 and this other one under UNIX'. #define is not part of the C/C++ language, so don't use it as part of your working code.

2. Indent your code, be consistent with your spacings

   The easiest thing you can do to make your code a bit more readable is to indent it. All IDEs provide some sort of automatic indentation. Under Visual Studio .NET it is under Edit -> Advanced -> Format Selection. It takes a second to indent your code and makes it much easier to read it later.

   It is OK to have your own style, but you need to be consistent.

   
   cin<
   
   I am not going to argue for one style over another, but I will argue that you should be consistent in your code.
   
   
   
   You know when I said "it is OK to have your own style", I lied! It is
   not OK to have your own style, especially if you are new to
   programming. That only invites chaos. Find a style and adopt it as
   your own.  Good places to start Mozilla
   Coding Style Guide, the combined list of C and C++ Style
   Guides, Horstmann's
   Guide, Programming in
   C++, Rules and Recommendations form a Swedish telecomunications
   company, Todd's
   C++ Coding Standard which provide plenty of examples, and many
   many others you can find on the web.
   
   
   You may even want to think about how to automtically generate
   documentation using something like DOCYGEN and
   adjust your style appropriately.
   
   

3. Global variables are not evil

   Global variables are not necessarily evil, but defining 'int i;' as a global variable is certainly evil. Global variables can even make code cleaner if used well, as long as you carefully consider whether something needs to be a global variable or not. Consider the alternatives, a static variable as part of a class, a singleton instance, ...

4. Do not use absolute file pathnames

   Does your program really need to read "d:\\myprogram\\config.ini"? What if I don't have a D drive, does that mean I cannot even run the program? Windows is not always installed on the C drive either. Make your program flexible. Who knows maybe you will want to run it on your next machine or maybe somebody may run it on their own machine on eday!

5. Prefer for loops over while loops

   for loops allow you to initialise variables, so given a choice, you should prefer for loops. The code below, whis is from an actual student assignment violates this rules (as well as common sense).

   
   int i=0;
   for(int j=0;j<9;j++)
   {
       i=1;
       while(i<=10)
       {
            // stuff 
            i++;
       }
   }
   

6. Name your files in a meaningful fashion

   Worst named file competion, cadidates are: file1.cpp, this.cpp, 1.cpp, mine.cpp, ass1.cpp

   Is it too much to ask for a hint between file name and file contents?

7. Comments -- do we really need them?

   Do we need comments? Yes, we do need comments. Some comments at the top of the file indicating date, author and functionality for that file is a good start.

   Does every function need some comment? Opinion varies on this issue. I am happy with commenting only interesting and important functions rather than trying to document every function and variable.

   Large chunks of commented out code need to be cleaned up before the program is finalised. Ditto for any functions or files that are not used by the program. They can move on to a happeir place, maybe another program but they certainly don't need to be included in this one.

8. Compilation warnings need to be cleaned up or suppressed

   Your program should not produce any warning messages when compiled. Some compilers can be picky about comparing int and 'unsigned int' and other matters. Either you should fix the problem or you should put in the appropriate compiler settings to suppress these messages. Visual Studio .NET uses '#pragma warning( disable : XXX )'. This way you know what warnings you are ignoring.

9. Memory management

   Writing a program without any memory leaks is difficult but not impossible. If you reserve any memory space using malloc or new, you will need to use delete (or delete[] for arrays) to return the memory back to the system.

   There are whole books on memory management, so I won't say much more about it over here other than 'if you allocate, you must deallocate', user destructors for your classes, pay attention when deleting an array or clearing a vector that contains pointers to objects, you need to delete individual objects as well.

UTS :: Faculty of IT :: Software Engineering :: Yusuf Pisan