Checklist and general advise for programming assignments

Do

• Get past compile errors quickly. Keep in mind that the program does not necessarily work just because the compiler accepts it. Do not let a lot of compile errors scare you. One missing semicolon can yield many compiler error messages.

• Always compile with warnings turned on. Do not ignore warnings just because you don't understand them. The compiler is usually calling your attention to something that is important. To use g++ with warnings turned on, you can write

      alias compile "g++ -Wall -g -O -Wshadow"
    

  in a terminal window. From then on, in that window, to compile a program foo.cc write

      compile foo.cc
    

  (Note: -O is dash capital O.)

  (You can save yourself more typing by using !! to redo the most recent command, and !c to redo the most recent command that started with a c.)

• Hand simulate your functions on simple inputs. Check that they seem to be working. You will often discover errors faster this way than by running the program.

• Test your program thoroughly. Experts know that untested programs have a very high likelihood of being incorrect. At an absolute minimum, your tester should run every part of your program at least once. But that is rarely adequate. A high quality test tries many cases, including special or unusual cases. Some errors only show up if you run some part of the program two or three times.

  If you compile using g++ you can run your program by typing command

        a.out
    

• Wherever possible, write testers that can run without user interaction, and that check their own results. If you have tests like this, you will tend to use them, since they are easy to run. Tests that require extensive user interaction are run infrequently, and so are less useful.

Don't

• Never type a program in a text processor such as Microsoft word.

• Do not let the compiler bully you into writing something that is nonsense, just to get your program to compile. Think about what you are writing, and be sure that it makes sense. You must be the boss.

• Do not modify a program and then turn it in without testing it again, regardless of how trivial the modification. It is easy to introduce a fatal error inadvertantly.

Before turning in your program

• Be sure that your name and the assignment number is in a comment promininently located at the top of every file that you turn in.

• Check that the program is well-indented.

• Check that all parts of the code have been tested. Try all possible kinds of answers. Make sure, at a minimum, that every line of code that you have written, and every part of every line, has been executed during your tests. Check that the results of the tests are correct.

• Proofread the program, including its documentation. Check that every function has a clear and correct contract. Check that every parameter of every function is documented in the contract. Be sure that spelling and punctuation in documentation are correct.

  Proofread the code. Does it make sense? Can you understand what it is saying? Are variable names sensible? If not, improve the program.