We often hear that naming in software is difficult, and it certainly can be. But equally, it is an essential part of the job, so the proper attitude would be to spend some time and effort and improve our skills. Or, we could find another line of work. It’s just that important.

I have done extensive work in legacy projects for numerous employers. And by legacy, I do not mean that the product is no longer in development, but that it has been many years in development. Myriad challenges are altogether normal in old code, and naming is just one of them, but it is a serious one, as bad naming impedes comprehension.

It is common in legacy code to find very long routines, as well as badly named routines. The combination is particularly challenging for maintenance. Of course, it is difficult in such cases to improve the naming, since it is difficult to discern what the routine is doing. But you can approach it in a methodical manner.

First, extract nested routines. Good candidates will include lines of assignment statements. Or blocks which are saving to a database. Group these operations as cleanly as possible, and put them in nested routines. Practice good naming on those new routines. Keep at it, until you find no more obvious candidates for removal to small routines. You should find that the outer routine is becoming more comprehensible. You may also find that you can now improve on the names of those routines.

Next, look for other large routines in the same module which offer such possibilities. Repeat the process above.

Keep in mind that in this rework you must avoid altering the sequence of operations. If you can do that, the risk of introducing defects is small.

With luck, you may find that some of these nested routines are nearly identical to one another. Where that happens, consider creating a private class member routine which can replace the duplicates. That’s a significant improvement, and well worth the effort. Over time, you may also find that some of these private members match routines in other classes. At that point, you must consider whether to create a new module which consolidates those routines, and allows removing the duplicated code. Whether to use a class, or individual routines is a call you must make.

What of new code?

In new code work, we hope you are following good practices:

• Keep routines short and focused.
• Make your names document the functions.
• DRY: Don’t Repeat Yourself.

But for now, and the near future, give particular attention to naming. Don’t be the one who just says “Naming is hard!” Do better!