Software Development Pointers
- Always have code that compiles.
- Start by writing core class and function declarations, and stubs
for all functions (including main). Write all of your file, class
and function headers now (you can change them later if necessary).
Write the makefile and make sure the project compiles before
beginning the real coding.
- As you develop your code, compile VERY frequently, on the order of
every 3-10 lines. You don't necessarily have to test your code each
time, just make sure there are no compiler errors. (Having an extra
terminal open makes this easy.)
- Practice incremental development.
- Always have code that mostly works and does not crash or hang.
- This makes it possible to test each new addition simply by
running the program (or call the function).
- If you can't finish the project, you can still potentially get
full credit for each component of the project that you did
- Before making major changes, make a backup of the current file
or the entire project folder (depending on the scope of the
- Don't try to solve complicated problems all at once. Get some of
the framework in place (initial steps, outer loops, etc) and make
sure those steps are working before continuing.
- If you do this, you can be fairly certain that any bugs that
come up are in the code you just wrote. Tracking down bugs is one
of the biggest time sinks in programming.
- If you realize that you are doing something the wrong way, there
will be much less code to rewrite.
- Document your code as you go.
- Tell what you're going to do before you do it, for everything
except very trivial code. Verbalizing your plans will force you to
check that what you're doing makes sense.
- Do the majority of your testing as you go.
- Again, this helps you avoid searching for a bug in some code
you wrote long ago.
- Also, you're more likely to remember the relevant tests for
- Test every possibility.
- Make sure every logic path (if-else, switch-case, loop conditions,
mid-loop breaks) works as intended.
- Make sure your program works for a variety of input, not just a
- This time, you're not thinking about your code's structure, but
trying to find any input that might not work as expected.
- Check for input errors (e.g., bad input that doesn't necessarily
have a correct output). Even if your documentation states that some
input will have undefined output, you at least need to make sure
your program won't crash.
Last updated 12/29/12