Most (if not all) projects are part of a larger research agenda. This means that a project must be maintainable for a period much longer than your direct involvement and it therefore must be left in a state where another student can continue the project without having to re-implement your work.

Projects completed under my direction use a set of tools available under UNIX which simplify the process maintaining code. This includes tools to help compile, track and document code. All persons working on projects MUST produce code which is compatible with these tools and standards.

Basic Tools

My primary, preferred and recommended editor is XEmacs. It is an incredibly powerful editor with over 20 years of history behind it. It has been developed and refined by the best UNIX programmers ever - to use it is to love it.

My preferred compiler is g++ and my preferred debugger is gdb. Both are text-based and easy to use once you get to know them. A reasonable alternative to gdb is ddd, a GUI debugger for UNIX.

Tools guide

Coding Style

Code style is largely a matter of preference - my own style emphasizes brevity while maintaining readability. The following guidelines apply primarily to C++ - if your project uses a different language you should be able to translate to appropriate constructs and consult with me if you are unclear on a particular issue.

Coding style guide

Compilation Control

Keeping track of compilation commands and dependencies is a horrid pain. The great joy of UNIX is that when something is too painful, there is usually a way to avoid the pain. In UNIX this is called Make and every piece of code I look at must use Make for compilation.

For little baby programs like assignments, I am perfectly satisfied with make. For real programs, it is still too much work, especially when users of your program need to install it at a remote site. The fine people at GNU have a developed a configuration and compilation system called autoconf which considerably simplifies the process.

Autobuild guide

Revision Control

A project will go through lots of changes over it's lifetime. When one person starts a project and another continues or when two people are working from the same codebase at the same time it often becomes confusing who is doing what to which file at which time.

CVS is a revision control system used for all substantial projects conducted under my direction. It is a network aware system which allows concurrent editing of files, branching, merging and logging.

CVS guide

Documentation

Sigh... this part is as necessary as it is hated. Failure to document a project is the number one reason why I end up throwing them away.... The trick to doing proper documentation is a proper tool, and for my projects I prefer a system called Doxygen. It is a semi-automatic documentation generator which extracts comments from code and produces a variety of output formats including HTML, LaTeX and RTF.

Doxygen guide

Cookbook

A cookbook is no substitute for understanding...

On the other hand, doing it right is a grand substitue, so I have developed a set of templates and recipies you can follow until enlightenment is achieved.

Last modified: Fri Jan 18 11:13:25 EST 2002