Refactoring and Short Names

There’s an old saw in certain segments of the programming world that sometimes it’s way better to use a short name for a variable. The classic example is a loop index. You get a loop that looks like this:

    ComplexObject[] objs = getComplexObjects();
    for(int i = 0; i < objs.length; i++) {
        objs[i].propertyOne = valueOne;
        objs[i].propertyTwo = valueTwo;
        //...
        objs[i].propertyNinetyNine = valueNinetyNine;
    }

Which, fair enough, would be a pain in the ass to type out with a more elaborate name. I'm ignoring the other problems with this code for illustrative purposes, but obviously there's more wrong here than just the way the objects are named. Focusing only on the names, however, refactoring completely transforms this scenario. Let's say that you write the above loop, and then someone comes along and says "Dear God man", and begs you to change the names to explanatory phrases. What is the cost of that change? In a non-refactoring-aware environment, it's the cost of changing the name of the array AND the loop index for the initialization and every single property assignment.

In a refactoring-aware environment, it's O(1). Right click, pick Refactor->Rename, type in the text, and you are done. This is one area where refactoring really makes a difference in the long-term maintainability of code. You don't have to make large investments to rename local variables, or methods, or class members, or any number of other items. Instead you can simply use the "fast" name when writing your code and the "right" name when you're ready to commit.

I'm gonna call this kind of process optimization "refactoring aware programming"; something with that name probably already exists, but for my purposes that's what we're doing there - we can write code quickly with the assurance we have a safe means of making improvements when it becomes appropriate to do so.