Naming Variables

Overview

The most important consideration in naming a variable is that the name fully and accurately describes the entity the variable represents.

Core principle: A variable and its name are essentially the same thing. The goodness or badness of a variable is largely determined by its name.

Name quality = Design quality. If you struggle to name something well, that's a warning sign about the design.

When to Use

Always use when:

• Naming any variable, function, class, parameter, constant
• Reviewing code with unclear names
• Struggling to understand what a variable does

Warning signs you need better names:

• Variables named x, x1, x2, temp, data, info, val
• Can't remember what a variable does
• Need to search back to find variable's purpose
• Abbreviations that aren't obvious
• Names that could mean multiple things
• Struggling to name something (indicates design problem)

Naming Principles

1. Describe What, Not How

Problem-oriented (what it represents) not solution-oriented (how it's implemented):

✅ Good: employeeData, printerReady, totalRevenue ❌ Bad: inputRec, bitFlag, calcVal

The bad names describe computing concepts (input, record, bit, calculation). Good names describe the problem domain (employee, printer, revenue).

2. Use Optimal Name Length

Optimal: 10-16 characters average

• Too short: doesn't convey meaning
• Too long: hard to type, obscures structure

Exception: Short names OK for very limited scope (loop index i in 3-line loop)

3. Scope Affects Name Length

• Long scope (class, global): Longer, more descriptive names
• Short scope (loop variable, local): Shorter acceptable
• Very short scope (5-line loop): i, j acceptable

Short name says: "I'm a scratch value with limited scope, don't look for me elsewhere"

4. State What Variable Represents

Effective technique: state in words what the variable represents. Often that statement IS the best name.

Example:

• "Running total of checks written to date" → runningTotal or checkTotal
• "Velocity of a bullet train" → velocity, trainVelocity, velocityInMph
• "Current date" → currentDate, todaysDate

5. Computed-Value Qualifiers at End

Put qualifiers like Total, Sum, Average, Max, Min, Count at the END:

✅ Good: revenueTotal, expenseAverage, pointsMax, customerCount ❌ Bad: totalRevenue mixed with revenueTotal (inconsistent)

Why:

• Most significant part (revenue, expense) at front, read first
• Symmetry: revenueTotal, revenueAverage, revenueMax
• Prevents confusion (totalRevenue vs revenueTotal - pick one convention)

Exception: Num is ambiguous

• At start = total: numCustomers (count of all customers)
• At end = index: customerNum (specific customer number)
• Better: Use Count for total, Index for specific: customerCount, customerIndex

6. Use Obvious Words

Don't be clever. Use the ordinary, obvious words:

✅ currentDate, employeeName, accountBalance ❌ cd, empNm, acctBal

Programmers sometimes overlook using ordinary words, which is often the easiest solution.

7. Be Specific, Not Generic

Names that are too general can be used for anything = not informative:

❌ Bad: x, temp, data, info, value, variable ✅ Good: discriminant, oldRoot, errorMessage, customerInfo, totalRevenue

Generic names acceptable ONLY for very limited scope.

Naming Conventions

Standard patterns for consistency and clarity:

Computed-Value Qualifiers

…