Rename Function/Variable

Intent

Change the name of a function or variable so it states what the thing actually is or does. The new name should let a reader understand the call without opening the body. Then update every caller to use it. Nothing about behaviour changes — only the words.

The smell

A name that misleads is worse than no name at all. A function called getCustomer that quietly creates a customer if one is missing, a variable named data that holds a single price, a flag named check that actually performs a deletion — each one forces the reader to ignore the name and study the body instead. That is the failure mode a good name exists to prevent. When you find yourself reading the implementation just to learn what something is called, rename it.

Before → After

A function whose name says far less than it does, plus a vague local variable. After, both names carry their meaning.

// Before
function calc(d: number): number {
  const x = d * 0.0085;
  return d + x;
}

const result = calc(1200);

// After
function applyDailyInterest(balance: number): number {
  const interest = balance * 0.0085;
  return balance + interest;
}

const balanceWithInterest = applyDailyInterest(1200);

# Before
def calc(d):
    x = d * 0.0085
    return d + x

result = calc(1200)

# After
def apply_daily_interest(balance):
    interest = balance * 0.0085
    return balance + interest

balance_with_interest = apply_daily_interest(1200)

// Before
func Calc(d float64) float64 {
    x := d * 0.0085
    return d + x
}

result := Calc(1200)

// After
func ApplyDailyInterest(balance float64) float64 {
    interest := balance * 0.0085
    return balance + interest
}

balanceWithInterest := ApplyDailyInterest(1200)

// Before
fn calc(d: f64) -> f64 {
    let x = d * 0.0085;
    d + x
}

let result = calc(1200.0);

// After
fn apply_daily_interest(balance: f64) -> f64 {
    let interest = balance * 0.0085;
    balance + interest
}

let balance_with_interest = apply_daily_interest(1200.0);

Mechanics

Decide on the new name. Say it out loud: does it describe the result, not the mechanics? Would a stranger understand the call site without reading the body?
If the function is part of a published API, consider keeping the old name as a thin wrapper that delegates to the new one, so existing callers do not break.
Rename the declaration. Lean on your editor’s rename-symbol refactoring if it is reliable, but verify the scope it touched.
Update every caller — and every comment or string that referred to the old name.
Run your tests. A rename should never change behaviour, so a green suite confirms you only moved words.
Once all callers use the new name, delete any temporary wrapper from step 2.

When to use / trade-offs

Rename whenever a name made you pause, whenever you had to read the body to learn what something was, or whenever the code’s behaviour drifted away from what the name first promised. It is the lowest-risk refactoring there is and one of the highest-value, because a clear name is read far more often than it is written.

The cost is mechanical churn across callers and, for public APIs, a possible breaking change. Mitigate it with automated rename tooling and, where a contract is at stake, a deprecation period. The risk is almost always worth it: every reader you save from a confusing name pays you back.