Tools

There is a plethora of debugging tools to help your fix your code, including many which are free. I prefer to use stand-alone tools that do not require me to be locked into any type of developement system. There are many Integrated Development Environments (IDE) out there that would work for those of you that prefer IDEs. IDEs typically come with a source code editor, a project planning tool, single click compilation, and a debugger. Many IDEs also support multiple programming languages (ie. C, C++, Fortran 77, Fortran 95, ...). When you create a program with an IDE, in addition to the files containing your source code, there is always at least one project file that describes the various preferences for your project. Microsoft Visual Studios in an example of a fully featured IDE (a non free suite).

Some very useful standalone tools include:

• gcore. Take core snapshots on SunOS without disturbing the process.
• dbx. Command line debugger for SunOS.
• gdb. Command line debugger available on most systems including Windows, Linux, SunOS, Mac OSX.
• ddd. Graphical interface to various command line debugger tools including gdb and dbx. Available on most unix type systems (Linux, SunOS, Mac OSX) although the University's SunOS machines appear to not have it correctly intalled. Displays data nicely.
• purify. A very expensive, but very thorough tool to detect programming errors. Available on Solaris as well as Linux. I'm not sure that the University has any licenses for this.
• valgrind. A very cheap (free), but quite useful tool to detect several types of programming errors and caveats. This tool is often compared to purify.

Some various IDEs include:

• GPS: The GNAT Programming System (http://libre.adacore.com/gps/).
• Microsoft Visual Studio

We are all very acquainted with software packages that have bugs: the word processor that dies just before you get a chance to save your document, the LabView that inadvertantly dies just before your data run is finished, the operating system that crashes because you tweaked a mirror on a laser table three flights of stairs away, etc. Though very annoying, these bugs are all semi-nonconsequential, in terms of programming. For example, it doesn't matter if your word processor has a bug which causes it to crash, as long as you are still able to produce a an error free document. The bug in the word processor has no effect on the paper that you cannot easily correct.

Results from computational software, on the other hand, are much more susceptible to errors in the software. A small typo can invalidate a whole run of simulated data and unless you are able to detect the invalidation, you will mistakenly present error-riddled simulations as correct.