Rename Variable
Before you begin: Variables, arithmetic, and scope.
Rename Variable changes a variable’s name so its meaning is easier to understand. The stored value and calculation stay the same. A good name can explain a unit, a domain concept, or a role that the old name left implicit. 1
Original version: two letters carry the calculation
A timer displays completed whole minutes from a nonnegative elapsed-second count. Fractional minutes are intentionally omitted.
public static class Timers
{
public static string Label(int s)
{
int m = s / 60;
return m + " minutes";
}
}def label(s):
m = s // 60
return str(m) + " minutes"The arithmetic suggests what the letters mean, but a reader has to reconstruct the units. In a longer method, s and m would be harder to keep straight.
Refactored version: the names explain the conversion
public static class Timers
{
public static string Label(int elapsedSeconds)
{
int completedMinutes = elapsedSeconds / 60;
return completedMinutes + " minutes";
}
}elapsedSeconds identifies the input unit. completedMinutes explains why integer division is appropriate: the label reports completed minutes, not a rounded estimate.
def label(elapsed_seconds):
completed_minutes = elapsed_seconds // 60
return str(completed_minutes) + " minutes"The same division now states its purpose through the names. label(125) still returns 2 minutes and label(59) still returns 0 minutes.
Rename the symbol, not every matching piece of text
Use a symbol-aware editor where possible. An unrestricted replacement can alter another variable with the same name, quoted data, or unrelated documentation. Check nested scopes and shadowed names.
A local-variable rename usually has a small compatibility surface. A parameter rename can affect callers using named arguments, as both languages permit here. A public field or serialized property can have still more consumers. Inspect those uses rather than assuming that every name is purely internal.
Short names remain useful in familiar, tiny scopes: an index i in a three-line loop may be clear. Longer is not automatically better. Prefer the shortest name that carries the information readers actually need, and avoid embedding an outdated implementation detail in it.
The example changes no arithmetic. If a clearer name reveals that the calculation is wrong, fix that behavior separately instead of disguising a logic change as a rename.