C Language

Principles Of Reuse

A programmer won't reuse a component unless three conditions are met:

* The programmer can find a suitable component
* The component can be used without too much work
* The component is reliable and performs adequately

The first condition requires a good "catalog" of components. Components should be indexed by various functional characteristics. For example, C++ "container" classes for various types would be listed in an index by container type (set, bag, ordered list, etc.) and by element type (integer, string, etc.). In addition, the catalog should contain both an abbreviated and a complete interface description for each component. (The need for explicit interface specifications may shock some programmers, but then they probably aren't the best programmers to write reusable components anyway.)

Unlike functions or classes that are used only in one program, reusable components have to be carefully designed so they are general enough to be used in a variety of applications (otherwise there may not be a large enough base of reuse to recover development costs), but specific enough to be easily used. In practice, this is a challenging goal, often requiring mastery of the art of programming to do well.

The last condition for reuse is that a component be "trustworthy." No programmer wants to reuse a component if that increases the chance of an application failure or slows down the application too severely. This means that reusable components must be carefully designed and implemented, and thoroughly tested before they become "public."

Certain practices can increase the chances for successful reuse. First, be sure somebody plays the role of "librarian" for all purchased and homegrown components. The librarian's responsibility is to keep the catalog of components up-to-date and easily accessible, either on-line or in hard copy. The librarian is also a good person to receive requests from other staff for various types of components that may not already be available.

You should maintain the components in the "production quality" library; treat them as you would the code in any production application. Don't put "almost complete" components in the "production quality" library. If you choose to make them available, isolate them in "as is" libraries with no "warranty."

In general, don't assign novices to write reusable components until they've had substantial experience writing application code and reusing components in their code. This is especially true of C++ classes, which can be very tricky to get right the first time.

Finally, reward programmers who build and use reusable components - these are the people who keep you out of the maintenance graveyard. Successful application development groups work cohesively, with attention to the overall results of the whole group, not just to individual achievements. "Team players" have always been more valuable than "lone cowboys"; but with the increasing importance of code reuse, a "team player" approach to development becomes especially critical.

You Can C Clearly Now

Just as C programming doesn't have to be a mysterious practice, neither does managing C development. Principles that apply to all software development are doubly important when working with C and C++ languages - careful attention to standards and processes, and using adequate tools to overcome weak areas of the languages and maintain control of application objects.

And most of all, it's a matter of attitude. Doing it the same old way won't work for programming in C or managing C development. A successful C programmer will take extra steps to guard against language traps or dangerous programming practices. Likewise, a successful manager will be sure that his or her programmers follow safe, standardized C programming practices. With the right attitude and a good set of programming guidelines, you can have "calm Cs ahead."