Chapter 11: The Power of Variable Names

11.1 Considerations in Choosing Good Names

You can't give a variable a name the way you give a dog a name-because it's cute or it has a good sound. Unlike the dog and its name, which are different entities, a variable and a variable's name are essentially the same thing. Consequently, the goodness or badness of a variable is largely determined by its name. Choose variable names with care.

Here's an example of code that uses bad variable names:

Java Example of Poor Variable Names

x = x - xx;
xxx = fido + SalesTax( fido );
x = x + LateFee( x1, x ) + xxx;
x = x + Interest( x1, x );

What's happening in this piece of code? What do $x1,xx$, and $xxx$ mean? What does fido mean? Suppose someone told you that the code computed a total customer bill based on an outstanding balance and a new set of purchases. Which variable would you use to print the customer's bill for just the new set of purchases?

Here's a version of the same code that makes these questions easier to answer:

Java Example of Good Variable Names

balance = balance - lastPayment;
monthlyTotal = newPurchases + SalesTax( newPurchases );
balance = balance + LateFee( customerID, balance ) + monthlyTotal;
balance = balance + Interest( customerID, balance );

In view of the contrast between these two pieces of code, a good variable name is readable, memorable, and appropriate. You can use several general rules of thumb to achieve these goals.

The Most Important Naming Consideration

The most important consideration in naming a variable is that the name fully and accurately describe the entity the variable represents. An effective technique for coming up with a good name is to state in words what the variable represents. Often that statement itself is the best variable name. It's easy to read because it doesn't contain cryptic abbreviations, and it's unambiguous. Because it's a full description of the entity, it won't be confused with something else. And it's easy to remember because the name is similar to the concept.

For a variable that represents the number of people on the U.S. Olympic team, you would create the name numberOfPeopleOnTheUsOlympicTeam. A variable that represents the number of seats in a stadium would be numberOfSeatsInTheStadium. A variable that represents the maximum number of points scored by a country's team in any modern Olympics would be maximumNumberOfPointsInModernOlympics. A variable that contains the current interest rate is better named rate or interestRate than $r$ or $x$. You get the idea.

Note two characteristics of these names. First, they're easy to decipher. In fact, they don't need to be deciphered at all because you can simply read them. But second, some of the names are long-too long to be practical. I'll get to the question of variablename length shortly.

Table 11-1 shows several examples of variable names, good and bad:

The names currentDate and todaysDate are good names because they fully and accurately describe the idea of "current date." In fact, they use the obvious words. Programmers sometimes overlook using the ordinary words, which is often the easiest solution. Because they're too short and not at all descriptive, $cd$ and $c$ are poor names. current is poor because it doesn't tell you what is current. date is almost a good name, but it's a poor name in the final analysis because the date involved isn't just any date, but the current date; date by itself gives no such indication. $x,x1$, and $x2$ are poor names because they're always poor names- $x$ traditionally represents an unknown quantity; if you don't want your variables to be unknown quantities, think of better names.

Names should be as specific as possible. Names like $x$, temp, and $i$ that are general enough to be used for more than one purpose are not as informative as they could be and are usually bad names.

Problem Orientation

A good mnemonic name generally speaks to the problem rather than the solution. A good name tends to express the what more than the how. In general, if a name refers to some aspect of computing rather than to the problem, it's a how rather than a what. Avoid such a name in favor of a name that refers to the problem itself.

A record of employee data could be called inputRec or employeeData. inputRec is a computer term that refers to computing ideas-input and record. employeeData refers to the problem domain rather than the computing universe. Similarly, for a bit field indicating printer status, bitFlag is a more computerish name than printerReady. In an accounting application, calcVal is more computerish than sum.

Optimum Name Length

The optimum length for a name seems to be somewhere between the lengths of $x$ and maximumNumberOfPointsInModernOlympics. Names that are too short don't convey enough meaning. The problem with names like $x1$ and $x2$ is that even if you can discover what $x$ is, you won't know anything about the relationship between $x1$ and $x2$. Names that are too long are hard to type and can obscure the visual structure of a program.

Gorla, Benander, and Benander found that the effort required to debug a program was minimized when variables had names that averaged 10 to 16 characters (1990). Programs with names averaging 8 to 20 characters were almost as easy to debug. The guideline doesn't mean that you should try to make all of your variable names 9 to 15 or 10 to 16 characters long. It does mean that if you look over your code and see many names that are shorter, you should check to be sure that the names are as clear as they need to be.

You'll probably come out ahead by taking the Goldilocks-and-the-Three-Bears approach to naming variables, as Table 11-2 illustrates.

The Effect of Scope on Variable Names

Are short variable names always bad? No, not always. When you give a variable a short name like $i$, the length itself says something about the variable-namely, that the variable is a scratch value with a limited scope of operation.

A programmer reading such a variable should be able to assume that its value isn't used outside a few lines of code. When you name a variable $i$, you're saying, "This variable is a run-of-the-mill loop counter or array index and doesn't have any significance outside these few lines of code."

A study by W. J. Hansen found that longer names are better for rarely used variables or global variables and shorter names are better for local variables or loop variables

(Shneiderman 1980). Short names are subject to many problems, however, and some careful programmers avoid them altogether as a matter of defensive-programming policy.

Use qualifiers on names that are in the global namespace If you have variables that are in the global namespace (named constants, class names, and so on), consider whether you need to adopt a convention for partitioning the global namespace and avoiding naming conflicts. In C++ and C#, you can use the namespace keyword to partition the global namespace.

C++ Example of Using the namespace Keyword to Partition the Global Namespace

namespace UserInterfaceSubsystem {
    ...
    // lots of declarations
    ...
}
namespace DatabaseSubsystem {
    ...
    // lots of declarations
    ...
}

If you declare an Employee class in both the UserInterfaceSubsystem and the DatabaseSubsystem, you can identify which you wanted to refer to by writing UserInterfaceSubsystem::Employee or DatabaseSubsystem::Employee. In Java, you can accomplish the same thing by using packages.

In languages that don't support namespaces or packages, you can still use naming conventions to partition the global namespace. One convention is to require that globally visible classes be prefixed with subsystem mnemonic. The user interface employee class might become uiEmployee, and the database employee class might become dbEmployee. This minimizes the risk of global-namespace collisions.

Computed-Value Qualifiers in Variable Names

Many programs have variables that contain computed values: totals, averages, maximums, and so on. If you modify a name with a qualifier like Total, Sum, Average, Max, Min, Record, String, or Pointer, put the modifier at the end of the name.

This practice offers several advantages. First, the most significant part of the variable name, the part that gives the variable most of its meaning, is at the front, so it's most prominent and gets read first. Second, by establishing this convention, you avoid the confusion you might create if you were to use both totalRevenue and revenueTotal in the same program. The names are semantically equivalent, and the convention would prevent their being used as if they were different. Third, a set of names like revenueTotal, expenseTotal, revenueAverage, and expenseAverage has a pleasing symmetry. A set of names like totalRevenue, expenseTotal, revenueAverage, and averageExpense doesn't appeal to a sense of order. Finally, the consistency improves readability and eases maintenance.

An exception to the rule that computed values go at the end of the name is the customary position of the Num qualifier. Placed at the beginning of a variable name, Num refers to a total: numCustomers is the total number of customers. Placed at the end of the variable name, Num refers to an index: customerNum is the number of the current customer. The $s$ at the end of numCustomers is another tip-off about the difference in meaning. But, because using Num so often creates confusion, it's probably best to sidestep the whole issue by using Count or Total to refer to a total number of customers and Index to refer to a specific customer. Thus, customerCount is the total number of customers and customerIndex refers to a specific customer.

Common Opposites in Variable Names

Use opposites precisely. Using naming conventions for opposites helps consistency, which helps readability. Pairs like begin/end are easy to understand and remember. Pairs that depart from common-language opposites tend to be hard to remember and are therefore confusing. Here are some common opposites:

• begin/end
• first/last
• locked/unlocked
• min/max
• next/previous
• old/new
• opened/closed
• visible/invisible
• source/target
• source/destination
• up/down

11.3 The Power of Naming Conventions

Some programmers resist standards and conventions-and with good reason. Some standards and conventions are rigid and ineffective-destructive to creativity and program quality. This is unfortunate since effective standards are some of the most powerful tools at your disposal. This section discusses why, when, and how you should create your own standards for naming variables.

Why Have Conventions?

Conventions offer several specific benefits:

• They let you take more for granted. By making one global decision rather than many local ones, you can concentrate on the more important characteristics of the code.
• They help you transfer knowledge across projects. Similarities in names give you an easier and more confident understanding of what unfamiliar variables are supposed to do.
• They help you learn code more quickly on a new project. Rather than learning that Anita's code looks like this, Julia's like that, and Kristin's like something else, you can work with a more consistent set of code.
• They reduce name proliferation. Without naming conventions, you can easily call the same thing by two different names. For example, you might call total points both pointTotal and totalPoints. This might not be confusing to you when you write the code, but it can be enormously confusing to a new programmer who reads it later.
• They compensate for language weaknesses. You can use conventions to emulate named constants and enumerated types. The conventions can differentiate among local, class, and global data and can incorporate type information for types that aren't supported by the compiler.
• They emphasize relationships among related items. If you use object data, the compiler takes care of this automatically. If your language doesn't support objects, you can supplement it with a naming convention. Names like address, phone, and name don't indicate that the variables are related. But suppose you decide that all employee-data variables should begin with an Employee prefix. employeeAddress, employeePhone, and employeeName leave no doubt that the variables are related. Programming conventions can make up for the weakness of the language you're using.

The key is that any convention at all is often better than no convention. The convention may be arbitrary. The power of naming conventions doesn't come from the specific convention chosen but from the fact that a convention exists, adding structure to the code and giving you fewer things to worry about.

When You Should Have a Naming Convention

There are no hard-and-fast rules for when you should establish a naming convention, but here are a few cases in which conventions are worthwhile:

• When multiple programmers are working on a project
• When you plan to turn a program over to another programmer for modifications and maintenance (which is nearly always)
• When your programs are reviewed by other programmers in your organization
• When your program is so large that you can't hold the whole thing in your brain at once and must think about it in pieces
• When the program will be long-lived enough that you might put it aside for a few weeks or months before working on it again
• When you have a lot of unusual terms that are common on a project and want to have standard terms or abbreviations to use in coding

You always benefit from having some kind of naming convention. The considerations above should help you determine the extent of the convention to use on a particular project.

Degrees of Formality

Different conventions have different degrees of formality. An informal convention might be as simple as "Use meaningful names." Other informal conventions are described in the next section. In general, the degree of formality you need is dependent on the number of people working on a program, the size of the program, and the program's expected life span. On tiny, throwaway projects, a strict convention might be unnecessary overhead. On larger projects in which several people are involved, either initially or over the program's life span, formal conventions are an indispensable aid to readability.

11.4 Informal Naming Conventions

Most projects use relatively informal naming conventions such as the ones laid out in this section.

Guidelines for a Language-Independent Convention

Here are some guidelines for creating a language-independent convention:

Differentiate between variable names and routine names

The convention this book uses is to begin variable and object names with lower case and routine names with upper case: variableName vs. RoutineName().
``

Differentiate between classes and objects

The correspondence between class names and object names-or between types and variables of those types-can get tricky. Several standard options exist, as shown in the following examples:

Option 1: Differentiating Types and Variables via Initial Capitalization

Widget widget;
LongerWidget longerWidget;

Option 2: Differentiating Types and Variables via All Caps

WIDGET widget;
LONGERWIDGET longerWidget

Option 3: Differentiating Types and Variables via the "t_" Prefix for Types

t_Widget Widget;
t_LongerWidget LongerWidget;

Option 4: Differentiating Types and Variables via the " a " Prefix for Variables

Widget aWidget;
LongerWidget aLongerWidget;

Option 5: Differentiating Types and Variables via Using More Specific Names for the Variables

Widget employeeWidget;
LongerWidget fullEmployeeWidget;

Each of these options has strengths and weaknesses. Option 1 is a common convention in case-sensitive languages including C++ and Java, but some programmers are uncomfortable differentiating names solely on the basis of capitalization. Indeed, creating names that differ only in the capitalization of the first letter in the name seems to provide too little "psychological distance" and too small a visual distinction between the two names.

The Option 1 approach can't be applied consistently in mixed-language environments if any of the languages are case-insensitive. In Microsoft Visual Basic, for example, Dim widget as Widget will generate a syntax error because widget and Widget are treated as the same token.

Option 2 creates a more obvious distinction between the type name and the variable name. For historical reasons, all caps are used to indicate constants in C++ and Java, however, and the approach is subject to the same problems in mixed-language environments that Option 1 is subject to.

Option 3 works adequately in all languages, but some programmers dislike the idea of prefixes for aesthetic reasons.

Option 4 is sometimes used as an alternative to Option 3, but it has the drawback of altering the name of every instance of a class instead of just the one class name.

Option 5 requires more thought on a variable-by-variable basis. In most instances, being forced to think of a specific name for a variable results in more readable code. But sometimes a widget truly is just a generic widget, and in those instances you'll find yourself coming up with less-than-obvious names, like genericWidget, which are arguably less readable.

In short, each of the available options involves tradeoffs. The code in this book uses Option 5 because it's the most understandable in situations in which the person reading the code isn't necessarily familiar with a less intuitive naming convention.

Identify global variables

One common programming problem is misuse of global variables. If you give all global variable names a $g\mathrm{\_}$prefix, for example, a programmer seeing the variable $g\mathrm{\_}$RunningTotal will know it's a global variable and treat it as such.

Identify member variables

Identify a class's member data. Make it clear that the variable isn't a local variable and that it isn't a global variable either. For example, you can identify class member variables with an $m_{-}$prefix to indicate that it is member data.

Identify type definitions

Naming conventions for types serve two purposes: they explicitly identify a name as a type name, and they avoid naming clashes with variables. To meet those considerations, a prefix or suffix is a good approach. In C++, the customary approach is to use all uppercase letters for a type name-for example, COLOR and MENU. (This convention applies to typedefs and structs, not class names.) But this creates the possibility of confusion with named preprocessor constants. To avoid confusion, you can prefix the type names with $t_{-}$, such as $t\mathrm{\_}$Color and $t\mathrm{\_}$Menu .

Identify named constants

Named constants need to be identified so that you can tell whether you're assigning a variable a value from another variable (whose value might change) or from a named constant. In Visual Basic, you have the additional possibility that the value might be from a function. Visual Basic doesn't require function names to use parentheses, whereas in C++ even a function with no parameters uses parentheses.

One approach to naming constants is to use a prefix like $c_{-}$for constant names. That would give you names like c_RecsMax or c_LinesPerPageMax. In C++ and Java, the convention is to use all uppercase letters, possibly with underscores to separate words, RECSMAX or RECS_MAX and LINESPERPAGEMAX or LINES_PER_PAGE_MAX.

Identify elements of enumerated types

Elements of enumerated types need to be identified for the same reasons that named constants do-to make it easy to tell that the name is for an enumerated type as opposed to a variable, named constant, or function. The standard approach applies: you can use all caps or an $e_{-}$or $E_{-}$prefix for the name of the type itself and use a prefix based on the specific type like Color_ or Planet_ for the members of the type.

Identify input-only parameters in languages that don't enforce them

Sometimes input parameters are accidentally modified. In languages such as C++ and Visual Basic, you must indicate explicitly whether you want a value that's been modified to be returned to the calling routine. This is indicated with the *, and const qualifiers in C++ or ByRef and ByVal in Visual Basic.

In other languages, if you modify an input variable, it is returned whether you like it or not. This is especially true when passing objects. In Java, for example, all objects are passed "by value," so when you pass an object to a routine, the contents of the object can be changed within the called routine (Arnold, Gosling, Holmes 2000).

In those languages, if you establish a naming convention in which input-only parameters are given a const prefix (or final, nonmodifiable, or something comparable) , you'll know that an error has occurred when you see anything with a const prefix on the left side of an equal sign. If you see constMax.SetNewMax( ... ), you'll know it's a goof because the const prefix indicates that the variable isn't supposed to be modified.

Format names to enhance readability

Two common techniques for increasing readability are using capitalization and spacing characters to separate words. For example, GYMNASTICSPOINTTOTAL is less readable than gymnasticsPointTotal or gymnastics_point_total. C++, Java, Visual Basic, and other languages allow for mixed uppercase and lowercase characters. C++, Java, Visual Basic, and other languages also allow the use of the underscore (_) separator.

Try not to mix these techniques; that makes code hard to read. If you make an honest attempt to use any of these readability techniques consistently, however, it will improve your code. People have managed to have zealous, blistering debates over fine points such as whether the first character in a name should be capitalized (TotalPoints vs. totalPoints), but as long as you and your team are consistent, it won't make much difference. This book uses initial lowercase because of the strength of the Java practice and to facilitate similarity in style across several languages.

Guidelines for Language-Specific Conventions

Follow the naming conventions of the language you're using. You can find books for most languages that describe style guidelines. Guidelines for C, C++, Java, and Visual Basic are provided in the following sections.

C Conventions

Several naming conventions apply specifically to the C programming language:

• $c$ and $ch$ are character variables.
• $i$ and $j$ are integer indexes.
• $n$ is a number of something.
• $p$ is a pointer.
• $s$ is a string.
• Preprocessor macros are in ALL_CAPS. This is usually extended to include typedefs as well.
• Variable and routine names are in all_lowercase.
• The underscore (_) character is used as a separator: letters_in_lowercase is more readable than lettersinlowercase.

These are the conventions for generic, UNIX-style and Linux-style C programming, but C conventions are different in different environments. In Microsoft Windows, C programmers tend to use a form of the Hungarian naming convention and mixed uppercase and lowercase letters for variable names. On the Macintosh, C programmers tend to use mixed-case names for routines because the Macintosh toolbox and operating-system routines were originally designed for a Pascal interface.

C++ Conventions

Here are the conventions that have grown up around C++ programming:

• $i$ and $j$ are integer indexes.
• $p$ is a pointer.
• Constants, typedefs, and preprocessor macros are in ALL_CAPS.
• Class and other type names are in MixedUpperAndLowerCase().
• Variable and function names use lowercase for the first word, with the first letter of each following word capitalized-for example, variableOrRoutineName.
• The underscore is not used as a separator within names, except for names in all caps and certain kinds of prefixes (such as those used to identify global variables).

As with $C$ programming, this convention is far from standard and different environments have standardized on different convention details.

Java Conventions

In contrast with C and C++, Java style conventions have been well established since the language's beginning:

• $i$ and $j$ are integer indexes.
• Constants are in ALL_CAPS separated by underscores.
• Class and interface names capitalize the first letter of each word, including the first word-for example, ClassOrInterfaceName.
• Variable and method names use lowercase for the first word, with the first letter of each following word capitalized-for example, variableOrRoutineName.
• The underscore is not used as a separator within names except for names in all caps.
• The get and set prefixes are used for accessor methods.

Visual Basic Conventions

Visual Basic has not really established firm conventions. The next section recommends a convention for Visual Basic.

Mixed-Language Programming Considerations

When programming in a mixed-language environment, the naming conventions (as well as formatting conventions, documentation conventions, and other conventions) can be optimized for overall consistency and readability-even if that means going against convention for one of the languages that's part of the mix.

In this book, for example, variable names all begin with lowercase, which is consistent with conventional Java programming practice and some but not all C++ conventions. This book formats all routine names with an initial capital letter, which follows the C++ convention. The Java convention would be to begin method names with lowercase, but this book uses routine names that begin in uppercase across all languages for the sake of overall readability.

Sample Naming Conventions

The standard conventions above tend to ignore several important aspects of naming that were discussed over the past few pages-including variable scoping (private, class, or global), differentiating between class, object, routine, and variable names, and other issues.

The naming-convention guidelines can look complicated when they're strung across several pages. They don't need to be terribly complex, however, and you can adapt them to your needs. Variable names include three kinds of information:

• The contents of the variable (what it represents)
• The kind of data (named constant, primitive variable, user-defined type, or class)
• The scope of the variable (private, class, package, or global)

Tables 11-3, 11-4, and 11-5 provide naming conventions for C, C++, Java, and Visual Basic that have been adapted from the guidelines presented earlier. These specific conventions aren't necessarily recommended, but they give you an idea of what an informal naming convention includes.

Sample Naming Conventions for C++ and Java

Sample Naming Conventions for C

Because Visual Basic is not case-sensitive, special rules apply for differentiating between type names and variable names. Take a look at Table 11-5.

Sample Naming Conventions for Visual Basic

11.7 Kinds of Names to Avoid

Here are some guidelines regarding variable names to avoid:

Avoid misleading names or abbreviations

Make sure that a name is unambiguous. For example, FALSE is usually the opposite of TRUE and would be a bad abbreviation for "Fig and Almond Season."

Avoid names with similar meanings

If you can switch the names of two variables without hurting the program, you need to rename both variables. For example, input and inputValue, recordNum and numRecords, and fileNumber and fileIndex are so semantically similar that if you use them in the same piece of code you'll easily confuse them and install some subtle, hard-to-find errors.

Avoid variables with different meanings but similar names

If you have two variables with similar names and different meanings, try to rename one of them or change your abbreviations. Avoid names like clientRecs and clientReps. They're only one letter different from each other, and the letter is hard to notice. Have at least two-letter differences between names, or put the differences at the beginning or at the end. clientRecords and clientReports are better than the original names.

Avoid names that sound similar, such as wrap and rap

Homonyms get in the way when you try to discuss your code with others. One of my pet peeves about Extreme Programming (Beck 2000) is its overly clever use of the terms Goal Donor and Gold Owner, which are virtually indistinguishable when spoken. You end up having conversations like this:

	I was just speaking with the Goal Donor-
	Did you say "Gold Owner" or "Goal Donor"?
	I said "Goal Donor."
	What?
	GOAL - - - DONOR!
	OK, Goal Donor. You don't have to yell, Goll' Darn it.
	Did you say "Gold Donut?"

Remember that the telephone test applies to similar sounding names just as it does to oddly abbreviated names.

Avoid numerals in names

If the numerals in a name are really significant, use an array instead of separate variables. If an array is inappropriate, numerals are even more inappropriate. For example, avoid file1 and file2, or total1 and total2. You can almost always think of a better way to differentiate between two variables than by tacking a 1 or a 2 onto the end of the name. I can't say never use numerals. Some real-world entities (such as Route 66 or Interstate 405) have numerals embedded in them. But consider whether there are better alternatives before you create a name that includes numerals.

Avoid misspelled words in names

It's hard enough to remember how words are supposed to be spelled. To require people to remember "correct" misspellings is simply too much to ask. For example, misspelling highlight as hilite to save three characters makes it devilishly difficult for a reader to remember how highlight was misspelled. Was it highlite? hilite? hilight? hilit? jai-a-lai-t? Who knows?

Avoid words that are commonly misspelled in English

Absense, acummulate, acsend, calender, concieve, defferred, definate, independance, occassionally, prefered, reciept, superseed, and many others are common misspellings in English. Most English handbooks contain a list of commonly misspelled words. Avoid using such words in your variable names.

Don't differentiate variable names solely by capitalization

If you're programming in a case-sensitive language such as C++, you may be tempted to use frd for fired, FRD for final review duty, and Frd for full revenue disbursal. Avoid this practice. Although the names are unique, the association of each with a particular meaning is arbitrary and confusing. Frd could just as easily be associated with final review duty and FRD with full revenue disbursal, and no logical rule will help you or anyone else to remember which is which.

Avoid multiple natural languages

In multinational projects, enforce use of a single natural language for all code, including class names, variable names, and so on. Reading another programmer's code can be a challenge; reading another programmer's code in Southeast Martian is impossible.

A more subtle problem occurs in variations of English. If a project is conducted in multiple English-speaking countries, standardize on one version of English so that you're not constantly wondering whether the code should say "color" or "colour," "check" or "cheque," and so on.

Avoid the names of standard types, variables, and routines

All programminglanguage guides contain lists of the language's reserved and predefined names. Read the list occasionally to make sure you're not stepping on the toes of the language you're using. For example, the following code fragment is legal in PL/I, but you would be a certifiable idiot to use it:

if if = then then
    then = else;
else else = if;

Don't use names that are totally unrelated to what the variables represent

Sprinkling names such as margaret and pookie throughout your program virtually guarantees that no one else will be able to understand it. Avoid your boyfriend's name, wife's name, favorite beer's name, or other clever (aka silly) names for variables, unless the program is really about your boyfriend, wife, or favorite beer. Even then, you would be wise to recognize that each of these might change, and that therefore the generic names boyfriend, wife, and favoriteBeer are superior!

Avoid names containing hard-to-read characters

Be aware that some characters look so similar that it's hard to tell them apart. If the only difference between two names is one of these characters, you might have a hard time telling the names apart. For example, try to circle the name that doesn't belong in each of the following sets:

Pairs that are hard to distinguish include $(1$ and 1$),(1$ and I$),($. and,$),(0$ and O$),(2$ and $Z$), (; and :), ($S$ and 5), and ($G$ and 6).

Do details like these really matter? Indeed! Gerald Weinberg reports that in the 1970s, a comma was used in a Fortran FORMAT statement where a period should have been used. The result was that scientists miscalculated a spacecraft's trajectory and lost a space probe-to the tune of $\mathrm{\$}1.6$ billion (Weinberg 1983).

Key Points

• Good variable names are a key element of program readability. Specific kinds of variables such as loop indexes and status variables require specific considerations.
• Names should be as specific as possible. Names that are vague enough or general enough to be used for more than one purpose are usually bad names.
• Naming conventions distinguish among local, class, and global data. They distinguish among type names, named constants, enumerated types, and variables.
• Regardless of the kind of project you're working on, you should adopt a variable naming convention. The kind of convention you adopt depends on the size of your program and the number of people working on it.
• Abbreviations are rarely needed with modern programming languages. If you do use abbreviations, keep track of abbreviations in a project dictionary or use the standardized prefixes approach.
• Code is read far more times than it is written. Be sure that the names you choose favor read-time convenience over write-time convenience.