Get past compile errors quickly. Do not let a lot of compile errors scare you. One missing semicolon can yield many compiler error messages. If you do not understand why your program does not compile, ask for help.
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"
once 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. Keep in mind that the program does not necessarily work just because the compiler accepts it. Experts know that untested programs have a very high likelihood of being incorrect. 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 time consuming to use, so they are run infrequently, and are less useful.
Never type a program in a text processor such as Microsoft Word. Word is designed for producing human-readable works. Programs must be machine-readable, since the compiler reads them. Use a text editor.
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 engage in shotgun programming. This is where you find that your program does not work, but you are tired, and just want to make it work without finding out why it does not work. Instead, you try random modifications, hoping to hit upon the right fix. If you do this, you will only destroy your program. Think of yourself as a doctor. If there is something wrong with the patient, find out what is wrong before you try to fix the problem. Do not prescribe random medicines hoping that one of them will cure the patient. Diagnosis first, cure afterwards.
Do not modify a program and then turn it in without testing it again, regardless of how trivial the modification is. It is easy to introduce a fatal error inadvertantly.
Be sure that your name and the assignment number are 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?