The Joy of Manipulating Code Quickly and Safely

Even the trivial things are not

A common activity the vast majority of software engineers share is working with code. There are many programming languages out there, some are statically typed, while others dynamically. Some are object oriented, and some are functional. Others are still trying to make up their mind (just kidding, we love you Scala!!). Regardless of the programming language at hand, in the end, working with code means manipulating code. These manipulations can be read-only, e.g., code navigation, or mutating, where existing code is being changed, and/or new code is being written, or both.

Not only is manipulating code a very common activity for software engineers, some would argue that this activity is what takes up most of one's time as a software engineer, or at the very least, one of the top activities software engineers spend time on. Other activities includes consuming coffee, debugging, context gathering, etc. 

Manipulating code is not trivial. For example, in order to correctly change a variable's name, and for simplicity's sake let's assume it's a local variable, the following needs to happen:

1. Change the variable's name in its definition. This is usually the less tricky part, as this variable is defined in one place.
2. Update all call sites to use the new name. This part is much tricker, since it requires finding all the usages of a given variable, and updating them to use the new name.

Then came the IDEs

Luckily, modern IDEs offer automated code manipulation capabilities, which allow performing the above automatically, in a click of a shortcut. The direct benefit is twofold:

1. Saving time, no need to inspect code manually and haunt down individual usages in order to modify them.
2. Ensuring correctness, fine grained code changes are error prone when performed by humans, e.g., copy-paste errors, missing usages during code inspection, etc.

Modern IDEs can automatically perform a great number code manipulations on our behalf, making the changes quick and safe, in striking contrast to when these types of changes are performed manually, by human beings.

Automated code manipulation capabilities are commonly known as "automated refactoring" or "code refactoring".

Or did they?

Perhaps somewhat surprisingly, automated code refactoring is not as common as it should be, given its great benefits.

From my personal experience, two main factor contribute to this reality:

• Poor support in IDE of choice.

Some people still use editors where refactoring is poorly supported. Although I don't own any share of JetBrains, I have repeatedly recommended JetBrains made IDEs, and will keep doing so, partially due to their great support for automated code refactoring across a wide range of programming languages. Even the dynamic ones, where "there be dragons". In addition, JetBrains' consistent shortcuts make it extremely easy to use code refactoring across a wide range of scenarios.

"The IDE plays an important role in the adoption of refactoring tool support. IntelliJ IDEA users perform automated refactorings (71% done automatically) than Eclipse users (44%) and Netbeans users (50%)." [1]

• Lack of awareness/knowledge.

Automated code refactoring is easy to learn, and it does not take much effort to master. Moreover, if I had to throw in statistics, I'd probably say 80% of one's needs can be met with only 20% of the automated code refactoring catalog, e.g., rename, extract, move.

The Hidden Costs

Not using automated refactoring in the IDE also has indirect, or even hidden, costs. If code manipulation is laborious and unsafe, engineers are motivated to keep code changes to the bare minimum. This can be detrimental to the evolution of a software system for a number of reasons.

Short Term

Software development is an iterative process. Engineers often code an initial approach, which they then refine. The first iteration may focus on proving the viability of a given solution, while later iterations would deal with improving readability and structure. Unless code can be easily manipulated, iterations become laborious and costly, possibly resulting in the initial iterations also being the final ones.

Long Term

Lehman's laws teach us that a system must evolve in order to support new business needs and remain useful to its customers. Since code manipulation remains the fundamental activity in introducing new features to an existing system, making it easy for engineers to do so, is vital. 

Conclusions

The question of how fast, safe, and otherwise easy it is to manipulate code, is of the uttermost relevance for tech companies employing software engineers. Large software enterprises are likely to be especially interested in unlocking automated code refactoring from the IDE, since a simple math implies the benefit is linear in the number of software engineers employed.

This post described two concerns preventing a wider adoption of automated code refactoring. These concerns can be systematically addressed by guidance towards proper tools, and conducting professional training.