Elegant Coding (in lieu of cut-and-paste coding)

In this set of lectures, we wish to draw upon many things which we have seen earlier. By focussing on these experiences in a unified way, we hope to learn one very important lesson about programming.

Reuse of code fragments

At times, you may notice similarities between some code fragment you have already written and some code that needs to be written. It may seem very convenient to use a fragment of the existing code to aid you with the new code. Generally, this may lead to a decision to cut-and-paste that fragment to another location of the program, after which some minimal alterations might be needed. (BTW, the term cut-and-paste is probably not appropriate, as the original fragment remains; probably copy-and-paste is more fitting, but we will stick with tradition)

Have you ever found yourself in such a situation? If so you are to be commended for having the intuition for recognizing similarities between the processes; this demonstrates strong skills in abstraction. Unfortunately, the use of such cut-and-paste coding to take advantage of the similarities was almost surely a poor design. As a general rule cut-and-paste coding is never the best way!

What is the problem with that technique?

If you were only cutting and pasting one line of code, perhaps it is a non-issue; but imagine that you find a much larger, more complex fragment of code which is copied and modified in such a way. Furthermore, that code may later be copied and modified, and so on. The problem is in effectively maintaining this code over time. For example, imagine that there was a subtle bug in the portion of code that became the model for several such replications. Once you figure out how to fix the bug, you not only need to fix it in one place but perhaps in many different places; this takes more of your time as a programmer. Worse yet, since the many replications may have required various alterations, you must make sure to carefully fix the bug in each place while respecting the differences; it is quite likely that you end up having fixed the bug in some places but not all places, or of introducing new bugs in some places. In similar spirit, assume your code is bug-free but you discover an idea which can be used to improve the original version. You would need to go and enact the improvement in each place, and again carefully respect any needed alterations.

You are also more likely to create bugs and to have them go longer without being noticed. If you do have to adapt each copy individually, it is quite easy to make a mistake on one copy but not another.

A lesser concern is that the actual length of your source code becomes unnecessarily long in this way. Though computer memory is not necessarily scarce, it can be in some settings, and the software program itself must be written to disk to be saved, and must be loaded into main memory to be executed. If you land a job where they pay you per line of code that you produce, great; but in all other cases you should take pride in how few lines of code you have written, not how many.

For more reading on this, see:

So what is the elegant approach?

The key was the original intuition that there were similarities, as well as the observation about specific differences. More carefully pinpointing those similarities and differences is the key to finding the elegant solution. The programming techniques that can then be used are those which we have already seen: In fact, these are just a few such techniques. Think about how classes, inheritence, and other techniques we have seen help in taking advantage of similarities and differences. The entire object-oriented paradigm has found great success for just these reasons, ease of maintenance and reuse of code.

Another benefit is that you are more likely to find bugs when a single elegant code fragment is driving it all. This is because any bug will be a major bug, and likely to be discovered quickly. A single bug in one part of a cut-and-paste solutiion might go unnoticed for longer because its effect is not as obvious.

Blatantly obvious examples

More complex examples

With a handout distributed in lecture, we will revisit many of the earlier assignments from this course. This time, we will re-examine some of the tempting cut-and-paste approaches, as well as the elegant solutions which could have been used instead.


Michael Goldwasser
Last modified: Friday, 16 April 2004