I just realized that the copy I sent Pete of my article on Complexity was missing a section. Stupid me. As an exclusive, (and if you care
) here is the missing section which comes after the Oops, I Forgot section.
Reinventing the Wheel
When it comes to the subject of complexity, less code is better in a program. Any programming language comes with a set of internal functions and subroutines designed to help the programmer accomplish the task of creating a solution to a problem. There is no sense is rewriting an internal function, and adding additional code to a program, if the internal function works correctly.
For a stable programming language, using an internal function or subroutine will result in a smaller, faster and more stable program. The internal function will have been tested and debugged by the language creators, and since they know the internals of their language better than we do, it is a safe bet that their method is better than anything we could come up with in code. This is especially true of a language that has an optimizing compiler or interpreter.
Of course, there are instances where the internal function doesn?t work in the way we need it to work. Rather than rewriting the function, we should first ask ourselves if there is a way to accomplish the same task using a different internal function? Even if we have to use a couple of internal functions to accomplish the task, we are still better off than creating a large, hand-written function that adds to the complexity of the program. Only when we have no other option, should we bite the bullet and reinvent the wheel.
There are also cases where more than one language construct will accomplish the same task. The Windows API has several of these, where we can use either SendMessage or a built-in macro to set a value for a control. Keeping in mind that the goal is reduce the number of lines of code, the simpler method should be chosen. If both methods are equally simple, then clarity becomes the overriding factor in our choice.
A corollary to reinventing the wheel is using a language construct, not because we have to, but because we can. I call this the gee-whiz factor. We finally learned how to use pointers, and suddenly we find ourselves using pointers for everything. Gee-whiz, I can use pointers! For example, using our newfound mastery of pointers we create a pointer-based static array of types, even though a simple array would work equally well. Using a pointer-based array doesn?t add anything to the program except for increasing the gee-whiz factor and making the program harder to read and harder to debug. Simple is always better, and choosing the simple path will, in the long run, create a smaller and better program.