Meaningful Names — Practice Tasks¶

Twelve hands-on "rename it clean" exercises. Each gives a scenario, a code snippet riddled with bad names (Go, Java, or Python — the language varies), a precise instruction, and a collapsible solution with the cleaned code plus a one-sentence rationale for every rename. Difficulty climbs from spotting a single misleading variable to redesigning the vocabulary of a leaky public API.

Table of Contents¶

1. Task 1 — The variable that lies (Python, easy)
2. Task 2 — Single-letter abuse (Go, easy)
3. Task 3 — Noise words (Manager, Data, Info) (Java, easy)
4. Task 4 — Collection naming that lies about its type (Java, easy-medium)
5. Task 5 — Boolean names you can read out loud (Go, medium)
6. Task 6 — Hungarian notation in a typed language (Python, medium)
7. Task 7 — Disambiguating near-identical names (Java, medium)
8. Task 8 — Magic numbers and unsearchable names (Go, medium)
9. Task 9 — Domain vocabulary over invented words (Python, medium-hard)
10. Task 10 — Methods that don't match their verbs (Java, hard)
11. Task 11 — Naming a leaky public API (Go, hard)
12. Task 12 — Naming audit, open-ended (Python, hard)
13. Self-Assessment
14. Related Topics

How to Use¶

1. Read the scenario and the snippet. Before opening the solution, write your renamed version in a scratch file.
2. For each name you change, force yourself to say why in one sentence. If you can't, the new name is probably no better than the old one.
3. Open the solution. Compare not just the names but the reasoning — a name can be different and still wrong.
4. Apply the rename in a real editor with a rename refactoring (F2 / "Rename Symbol"), never find-and-replace on text. This is the difference between a safe rename and a silent bug.
5. The naming axes you are training are summarized below — every task exercises at least one.

Task 1 — The variable that lies (Python, easy)¶

Scenario: A teammate hands you this helper. It "works," but every reader stumbles on it because the names describe the wrong thing.

def f(d):
    l = 0
    for x in d:
        if x[1] > 0:
            l += x[1]
    return l

Instruction: This computes the total of all positive amounts in a list of (label, amount) pairs. Rename the function, the parameter, the accumulator, the loop variable, and the tuple access so the body reads as English. Do not change behavior.

def total_positive_amounts(entries):
    total = 0
    for label, amount in entries:
        if amount > 0:
            total += amount
    return total

Task 2 — Single-letter abuse (Go, easy)¶

Scenario: A retry loop. The single-letter names made sense to the author at 2 a.m. and to nobody since.

func retry(f func() error, n int, t time.Duration) error {
    var e error
    for i := 0; i < n; i++ {
        e = f()
        if e == nil {
            return nil
        }
        time.Sleep(t)
    }
    return e
}

Instruction: Keep the idiomatic short loop index i, but rename everything else to reveal intent. The signature is part of the public contract — its names show up in the caller's autocomplete and in docs.

func retry(operation func() error, maxAttempts int, backoff time.Duration) error {
    var lastErr error
    for attempt := 0; attempt < maxAttempts; attempt++ {
        lastErr = operation()
        if lastErr == nil {
            return nil
        }
        time.Sleep(backoff)
    }
    return lastErr
}

Task 3 — Noise words (Manager, Data, Info) (Java, easy)¶

Scenario: A class graduated from a tutorial. Every name carries a suffix that adds syllables but no meaning.

class UserDataManager {
    private List<UserInfo> userInfoList;

    public void processUserData(UserInfo userInfoData) {
        userInfoList.add(userInfoData);
    }

    public UserInfo getUserInfoData(String idString) {
        return userInfoList.stream()
            .filter(u -> u.getIdString().equals(idString))
            .findFirst()
            .orElse(null);
    }
}

Instruction: Strip the noise words (Data, Info, Manager, String suffix) and replace the vague verb process. The class is an in-memory store of users keyed by id.

class UserRepository {
    private final List<User> users = new ArrayList<>();

    public void add(User user) {
        users.add(user);
    }

    public Optional<User> findById(String id) {
        return users.stream()
            .filter(u -> u.id().equals(id))
            .findFirst();
    }
}

Task 4 — Collection naming that lies about its type (Java, easy-medium)¶

Scenario: A name claims one collection type while the code uses another — the classic "an accountList that is actually a Set" trap from the chapter.

class AccessControl {
    private Map<String, String> permissionList;
    private List<String> adminArray;

    public boolean hasPermission(String user, String action) {
        return action.equals(permissionList.get(user));
    }

    public void addAdmin(String user) {
        if (!adminArray.contains(user)) {
            adminArray.add(user);
        }
    }
}

Instruction: The names encode the wrong container and bake implementation into the API. Rename so each name describes the role, not the type — and fix the adminArray whose dedup logic reveals it should be a Set.

class AccessControl {
    private final Map<String, String> permissionByUser;
    private final Set<String> admins;

    public boolean hasPermission(String user, String action) {
        return action.equals(permissionByUser.get(user));
    }

    public void addAdmin(String user) {
        admins.add(user); // Set handles dedup for us
    }
}

Task 5 — Boolean names you can read out loud (Go, medium)¶

Scenario: A function bristling with booleans whose names invert the reader's mental model. Negative names plus a vague verb make every if a logic puzzle.

type Account struct {
    notActive    bool
    disableEmail bool
    flag         bool
}

func canSend(a Account) bool {
    return !a.notActive && !a.disableEmail && a.flag
}

Instruction: Rename the booleans so they read as positive assertions and so canSend becomes a sentence. State what flag actually means: the account has completed email verification.

type Account struct {
    isActive        bool
    emailEnabled    bool
    isEmailVerified bool
}

func canSendEmail(a Account) bool {
    return a.isActive && a.emailEnabled && a.isEmailVerified
}

Task 6 — Hungarian notation in a typed language (Python, medium)¶

Scenario: Code ported from a 1990s C codebase. Every name wears its type as a prefix — useless in a language where the type is one hover away and actively harmful when the type changes.

def calc(strName, intAge, lstScores, bIsAdmin, dctConfig):
    strGreeting = "Hello, " + strName
    fltAvg = sum(lstScores) / len(lstScores)
    if bIsAdmin and intAge >= 18:
        return strGreeting + dctConfig["adminSuffix"]
    return strGreeting + str(fltAvg)

Instruction: Strip the Hungarian type prefixes (str, int, lst, b, dct, flt) and let the names describe meaning. Add type hints instead — that is where type information belongs.

def build_greeting(
    name: str,
    age: int,
    scores: list[float],
    is_admin: bool,
    config: dict[str, str],
) -> str:
    greeting = "Hello, " + name
    average_score = sum(scores) / len(scores)
    if is_admin and age >= 18:
        return greeting + config["admin_suffix"]
    return greeting + str(average_score)

Task 7 — Disambiguating near-identical names (Java, medium)¶

Scenario: A method juggles four variables whose names differ by a single character. Reviewers keep approving bugs because custmer and customr look identical at a glance, and data1/data2 carry no distinguishing meaning.

void merge(Customer custmer, Customer customr, Account data1, Account data2) {
    custmer.setBalance(custmer.getBalance() + customr.getBalance());
    data1.setHistory(concat(data1.getHistory(), data2.getHistory()));
    custmer.setAccount(data1);
}

Instruction: The two customers are a survivor and a duplicate being absorbed; the two accounts are the kept account and the one being closed. Rename so the roles are obvious and no two names are near-typos of each other.

void merge(Customer primary, Customer duplicate, Account keptAccount, Account closedAccount) {
    primary.setBalance(primary.getBalance() + duplicate.getBalance());
    keptAccount.setHistory(concat(keptAccount.getHistory(), closedAccount.getHistory()));
    primary.setAccount(keptAccount);
}

Task 8 — Magic numbers and unsearchable names (Go, medium)¶

Scenario: A rate limiter. The constants are unsearchable (you can't grep for 60 and find this 60) and the names are too terse to convey units.

func allow(c int, t int64) bool {
    if c > 100 {
        return false
    }
    if time.Now().Unix()-t > 60 {
        return true
    }
    return c <= 100
}

Instruction: Replace the magic numbers 100 and 60 with named constants that include their units, and rename c and t. Make the window logic readable.

const (
    maxRequestsPerWindow = 100
    windowSeconds        = 60
)

func allow(requestCount int, windowStartUnix int64) bool {
    elapsedSeconds := time.Now().Unix() - windowStartUnix
    if elapsedSeconds > windowSeconds {
        return true // window expired; the counter will reset
    }
    return requestCount <= maxRequestsPerWindow
}

Task 9 — Domain vocabulary over invented words (Python, medium-hard)¶

Scenario: A payments module written by someone unfamiliar with the domain. The names are invented synonyms ("thing," "doStuff," "money2") where the business already has precise words: authorization, capture, refund, settlement.

class PaymentThing:
    def do_money(self, amount):
        self.held = amount          # reserve funds, not yet taken
        return self.held

    def take_money(self):
        self.taken = self.held      # actually move the held funds
        self.held = 0
        return self.taken

    def give_back(self, amount2):
        self.taken -= amount2       # return funds to the customer
        return amount2

Instruction: Replace the invented vocabulary with the standard payments domain terms. A payment is authorized (funds held), then captured (funds taken), and can later be refunded. Rename the class and all three methods and their fields.

class Payment:
    def authorize(self, amount):
        self.authorized_amount = amount    # funds reserved, not yet captured
        return self.authorized_amount

    def capture(self):
        self.captured_amount = self.authorized_amount
        self.authorized_amount = 0
        return self.captured_amount

    def refund(self, amount):
        self.captured_amount -= amount
        return amount

Task 10 — Methods that don't match their verbs (Java, hard)¶

Scenario: A service whose method names promise one thing and do another — the cruelest naming bug, because the names actively mislead callers into wrong assumptions.

class OrderService {
    // Returns null if not found, and also writes to the DB. Surprise!
    public Order getOrder(String id) {
        Order o = repo.find(id);
        if (o == null) {
            o = new Order(id);
            repo.save(o);   // side effect inside a "get"
        }
        return o;
    }

    // Despite "is", this mutates and returns void via exception
    public void isValid(Order o) {
        if (o.total() < 0) {
            throw new IllegalStateException("invalid");
        }
        o.setValidated(true);   // mutation inside an "is" check
    }

    // "list" but returns a single count
    public int listOrders(String customerId) {
        return repo.findByCustomer(customerId).size();
    }
}

Instruction: Each method's verb lies about its behavior. Rename so the verb matches the contract: a get must not mutate, an is/predicate must be side-effect-free and return a boolean, and a list must return a list. Where the behavior is genuinely "create if missing" or "validate and mark," name that.

class OrderService {
    // Honest name: it creates the order when absent.
    public Order getOrCreateOrder(String id) {
        Order order = repo.find(id);
        if (order == null) {
            order = new Order(id);
            repo.save(order);
        }
        return order;
    }

    // Honest name: it validates and records the result, returning nothing.
    public void validateAndMark(Order order) {
        if (order.total() < 0) {
            throw new IllegalStateException("invalid");
        }
        order.setValidated(true);
    }

    // Honest name: it counts.
    public int countOrders(String customerId) {
        return repo.findByCustomer(customerId).size();
    }
}

Task 11 — Naming a leaky public API (Go, hard)¶

Scenario: You are reviewing a soon-to-be-published package. The exported names leak implementation details, use inconsistent vocabulary for the same concept, and force callers to learn private jargon. Once published, every one of these names is a compatibility promise.

package store

// Exported names that leak internals and use 3 words for 1 concept.
type RedisThing struct{ /* ... */ }

func NewRedisThing(s string) *RedisThing { /* connect */ return nil }

func (r *RedisThing) DoGet(k string) ([]byte, error)        { /* ... */ return nil, nil }
func (r *RedisThing) PutData(k string, v []byte) error      { /* ... */ return nil }
func (r *RedisThing) RemoveKVPair(k string) error           { /* ... */ return nil }
func (r *RedisThing) GetAllKeysSlice() []string             { /* ... */ return nil }

Instruction: Design the public vocabulary. The package is a key-value cache; callers should not care that today it is Redis. Rename the type and methods so (a) no implementation (Redis, KVPair, Slice) leaks, (b) the verbs are consistent (Get/Set/Delete/Keys), and (c) the constructor and type names read well at the call site (store.New(...), c.Get(...)).

package store

// Cache is a key-value store. The backing technology is an implementation detail.
type Cache struct{ /* ... */ }

func New(addr string) *Cache { /* connect */ return nil }

func (c *Cache) Get(key string) ([]byte, error)    { /* ... */ return nil, nil }
func (c *Cache) Set(key string, value []byte) error { /* ... */ return nil }
func (c *Cache) Delete(key string) error            { /* ... */ return nil }
func (c *Cache) Keys() []string                     { /* ... */ return nil }

Task 12 — Naming audit, open-ended (Python, hard)¶

Scenario: A real-looking module landed in code review. List every naming problem you can find and give a one-line fix for each, then propose the renamed signatures.

class DataMgr:
    def __init__(self, l, d, flag1, flag2):
        self.l = l                 # list of orders
        self.d = d                 # dict: order_id -> status
        self.flag1 = flag1         # whether to send emails
        self.flag2 = flag2         # whether this is a dry run

    def proc(self, x):
        tmp = []
        for o in self.l:
            if o.amt > 0 and not self.flag2:
                tmp.append(o)
        return tmp

    def getStatusStr(self, intId):
        return self.d.get(intId)

    def doIt(self):
        # 40 lines that validate, charge, email, and log
        ...

Instruction: Produce a defect table (problem / where / fix) covering misleading names, noise words, single-letter abuse, Hungarian notation, boolean flags, and verbs that hide intent. Then write the corrected class skeleton.

class OrderProcessor:
    def __init__(
        self,
        orders: list[Order],
        status_by_order_id: dict[str, str],
        send_emails: bool,
        dry_run: bool,
    ):
        self.orders = orders
        self.status_by_order_id = status_by_order_id
        self.send_emails = send_emails
        self.dry_run = dry_run

    def select_chargeable_orders(self) -> list[Order]:
        return [
            order for order in self.orders
            if order.amount > 0 and not self.dry_run
        ]

    def find_status(self, order_id: str) -> str | None:
        return self.status_by_order_id.get(order_id)

    def process_orders(self) -> None:
        chargeable = self.select_chargeable_orders()
        for order in chargeable:
            self._validate(order)
            self._charge(order)
            if self.send_emails:
                self._notify(order)
            self._log_result(order)

Self-Assessment¶

Tick each box only if you can do it without looking back at the solutions.

• I can spot a name that lies (claims a type, count, or behavior it doesn't have) and rewrite it to state the truth.
• I remove noise words (Manager, Data, Info, Processor, Helper) unless they carry a real, recognized meaning (e.g. Repository).
• I avoid single-letter names except for the narrowest idiomatic loop indices, and I name even those when they represent a domain quantity.
• I never add Hungarian / type prefixes in a typed language; I put type information in the type, and meaning in the name.
• My booleans read as positive assertions (isActive, not notInactive) and my predicates read as sentences.
• I name collections by their content and role (permissionByUser), never by their container (permissionList), and I let the name reveal the right data structure.
• I disambiguate similar names with contrasting words (primary/duplicate), never numeric suffixes (data1/data2).
• I replace magic numbers with named constants that include their units (windowSeconds, not 60).
• I use the domain's ubiquitous language (authorize/capture/refund) instead of invented synonyms.
• My verbs match behavior: get doesn't mutate, is is side-effect-free, list returns a list.
• My public API names hide implementation (Cache, not RedisThing) and stay consistent (Get/Set/Delete).

Related Topics¶

• Meaningful Names — chapter README — the positive rules these tasks invert.
• junior.md — the beginner-level definitions of each anti-pattern.
• find-bug.md — buggy snippets where misleading names hide real defects.
• optimize.md — performance-flavored renaming and refactoring drills.
• naming-recipes.md — a quick-reference cookbook of naming conventions by category.
• Refactoring — code smells — many smells (Primitive Obsession, Data Clumps) are first detected through bad names.

Next: find-bug.md — find the defect that a misleading name is hiding in plain sight.