How I fix old code: I use the wisdom of those before me

I am often called in to a project to improve the code -- to make it more efficient, or more maintainable.  It seems that some programmers write code that is difficult to understand. (And luckily for me, a large number of them.)

I use the maxims provided by Kernighan and Plauger in their book "The Elements of Programming Style". Written in the 1970s, it contains wisdom that can be used by programmers today.

One of my favorites (possibly because so many programmers do not follow it) is "Each function should do one thing well."

Actually, Kernighan and Plauger wrote "Each module should do one thing well"; I am taking a (reasonable, in my mind) liberty to focus on functions. With today's object-oriented programming languages, the meaning of "module" is somewhat vague. Does it refer to the class (data, member functions, and all?) or does it refer to a separate compiled file (which may contain a single class, multiple classes, a portion of a class, or all three)? But such questions are distractions.

When I write code, I strive to make each function simple and easy to understand. I try to build functions of limited size. When I find that I have written a long function, I re-factor it into a set of smaller functions.

But these techniques are not used by all programmers. I have encountered no small number of programs which contain unreadable code. Some programs have large functions. Some programs have poor names of variables and functions. Some programs have complicated interactions between functions and data, otherwise known as "shared mutable state". It is these programs that I can improve.

Many times, I find that the earlier programmers have done a lot of the work for me, by organizing the code into reasonable chunks that just happen to be grouped into a single function. This makes it easy for me to create smaller functions, each doing one thing well.

I do more than reduce functions to maintainable sizes. I also move functions to their proper class. I find many functions have been placed in improper classes. Moving them to the right class makes the code simpler.

How does one know the proper class? I use this rule: When the function modifies data, the class that holds the data is the class that should hold the function. (In other words, only class functions can modify class data. Functions in cannot modify data in other classes.)

Functions that do not modify data but only read data belong to the class that holds the data.

If a function reads data from two classes, it is most likely doing too much and should be re-factored. If a function is changing data in two classes, it is definitely doing too much, and should definitely be re-factored. (These rules are for direct access of data. I have no problem with functions that invoke methods on multiple objects to retrieve or modify their data.)

These two simple rules ("each function should do one thing well" and "each function in its proper class"), give me guidance for most of my improvements. They have served me well.

I succeed because I simplify code. I simplify code by using not my own rules, but the maxims laid out by those who came before me.