Printers

Five steps for effectively reusing code

Programmers often reuse code to increase their efficiency and productivity. Here are five tips to help you with the challenging task of creating code that can be easily reused.


Coding for effective reuse can be tricky; it’s less of a science than an art form. Coders can sometimes go their entire careers without getting the knack of it. Here are five tips you should incorporate into your own habits to help make reusing your code easier.

1. Plan on reusing your code from the start
The first step is having the right attitude. Make code reuse a goal when you think about how you will solve a particular problem, and always assume what you are writing will need to be used again. If it was worth writing once, it is worth not writing again. While that routine you wrote to calculate the average annual return on a variable interest rate, foreign currency market asset will likely never be used outside of the calculator form, if it’s written as a self-contained function, moving that calculation will certainly be easier.

2. Keep your code general and abstract
I define “general” as solving a problem with as few special cases as possible. Reusable routines should be able to cope with many distinct instances of a problem. “Abstract,” on the other hand, is about hiding details and complexity. An excellent example of these concepts is the VB Printer object. The Printer object is both general (able to function without modification on many different models of printer) and abstract (hiding the complexities of printing a document from the programmer). Consider that without the Printer object, five separate API calls are required to print a simple text document—more if you want to control page size and alignment.

3. Encapsulate your code
Encapsulation is about removing dependencies. The term has been irrevocably attached to Object Oriented programming, but it really just means that the code you write should be self-contained with as few direct external references as possible. This means local declarations, no globals, and no direct references to forms or controls. Everything your routines need to know from the outside world should be received via input parameters. The reason for this should be obvious.

Assume you have a validation routine that directly references a field called txtPhoneNumber and you later decide to remove txtPhoneNumber, rename txtPhoneNumber, or apply the same validation to a new field, txtWorkNumber. In any of these examples, your validation routine would have to be rewritten. The more code you touch, the more potential there is to break it. At the very least, you’ll have to retest it. It is, therefore, to your advantage to encapsulate your validation routine into a function, pass the value or control to be validated via a parameter, and take some action based on the return value of that function.

4. Create tools
Strive not only to write code, but also to create tools. By their nature, tools are encapsulated and generalized. Think of a hammer. It requires no external parts to use and will work on any variety of nail, equally well in either hand.

A corollary point here is that tools require instructions to be used effectively. While you may intimately understand the hammer you have created, someone else may not. It is, therefore, important that you document the tools you create, and by this I do not mean just source comments. You should create an instruction manual for each tool you create. This manual should show an example, define any parameters or necessary dependencies, and detail any exceptions to its normal operation.

Make tools easy to use by being consistent and understandable. Allow other programmers to make safe assumptions about your code. For example, the Windows API usually returns a zero for success, so it’s generally safe for me to assume that a non-zero return code means what I was trying to do didn’t work correctly. In those cases where success is indicated by something other than zero, I have documentation that explains the special case.

5. Code small
My final point concerns source readability and my own version of probability theory. Endeavor to break up large routines into smaller routines that perform specific jobs. The reason for this is threefold. First, by breaking tasks into smaller routines, you are supporting the concept of encapsulation, and modifying the behavior of an application becomes easier. Secondly, a programmer trying to modify your source will likely have an easier time with a collection of five 30-line routines than he would with a single 150-line routine. Finally, breaking problem solutions into smaller blocks of code forces you to write a greater number of routines, thus increasing the chances that something useful will be written in a reusable format.

Wrapping up
Code reuse should be an objective in every development organization. It can improve application scalability, increase the productivity of less-technical programmers, and is the center of high-level programming languages (like VB). Utilizing the tips provided here can help individual programmers become more proficient at coding for reuse. Happy coding.

Lamont Adams is currently developing banking applications for Louisville, KY-based FAST Software. He has over four years of Windows development experience with Visual Basic and Access.

Editor's Picks