CS333 Project Notes

Sat Mar 18 10:08:27 EST 2000

While reading the projects, some issues came up multiple times, and I may not have noted them in the individual comments that were sent back to you. This page is a brief summary, in no particular order.

Users

It will help to have a clear idea of who might use your system: you can use that to focus on a manageable subset of what might otherwise be a big job, and it will help you to order the list of features and tasks. Several projects are aimed at beginners or novices or people taking the first course; that's a good example. If you are aiming at such people, you may also be able to find real users among your friends, or professors who would be interested in having your system; take advantage of these resources.

No matter what, you want to follow the KISS principle ("Keep It Simple, Stupid") as much as possible. One example: don't focus on efficiency early (if ever). It's unlikely that the speed difference between Java and C would ever matter for what you're doing.

Make versus Buy

It was not always clear whether a group was proposing to write their own version of something, modify an existing tool, or write their own from scratch. This should certainly be clear in your own minds, and also clear in your descriptions.

Bear in mind that even small modifications to big programs, like gcc, gdb, emacs, and so on, can turn into a time sink. Remember ed.c? gcc is about 200 times bigger.

In general, use what's already available unless building your own component is the point of what you're doing. For example, adding a regular expression search (and replace?) capability to your editor is a fine idea. But see if you can lift the code from the simple grep we did in class, or from ed.c, rather than inventing your own.

Learning Experience

It's a good idea to use the project to learn something new, like a language or a tool. But be a little careful if your plan requires you to learn a lot of new languages, new tools, and new environments.

This seems to apply in particular to Visual C++ and Microsoft Foundation Classes, which several groups want to use. My sense from personal experience and talking to colleagues is that MFC has a very steep learning curve, and you could spend a lot of time just getting off the ground. If no one on your team has C++ or MFC experience, and you want to use Windows, you might consider Visual Basic as an alternative; it's much easier to get started with, and has the same access to Windows and components as C++ does. (The instructor and at least some of the TA's profess total ignorance of MFC, and will not be able to help if you get stuck.)

Syntax Highlighting

Quite a few projects use this phrase without specifying just what that means. Keep in mind at least these two potential problems:

Interfaces

It really will help if you try to define and stick to clean interfaces between components. That will let you change or improve an implementation without affecting the rest of the program.

An example: several projects intend to provide revision control with RCS or CVS or perhaps something they create themselves. Don't use those directly. Instead, define an interface that specifies what revision control facilities you want, then write the implementation that maps these into whatever RCS or CVS provides. Similarly, define what syntax highlighting facilities you want in an interface; the simplest implementation will ignore requests, and you can gradually improve it as time permits.