Code Complete by Steve McConnell : Chapter 9

In this chapter, the author focuses on how to choose good names for data. The author suggests to have a readable, memorable and appropriate name for a variable. The author provides following guidelines for choosing a variable name:

1. The name of the variable should fully and accurately describe the entity the variable represents. The name would be long and easy to decipher. The author then provides some examples of good and bad variable names.
   
2. Variables with loop scope can be given short names and variables with global scope should be given long names.
3. Variables that contain computed values should have their names modified with a suffix representing the computed value, i.e. variables holding total, maximum, average should have total, max and avg as the suffix in the name. This convention makes sure that the significant part of the name comes first and duplicate names with the qualifier at the front and at the end, e.g. countEmployee and employeeCount are avoided.
   
4. Make use of precise opposites in names.

The author then provides guidelines for naming data in several common usage:

1. Loop Indexes:
• If the variable scope is within a loop, short names like i, j and k can be used.
• If the loop is longer or there are nested loops, it is better to give proper variable names to avoid index cross-talk.
2. Status Variables: Status variables should never have flag in its name. Flags should be assigned values and their values should be tested with enumerated types, named constants and global variables that act as named constants.
   
3. Temporary Variables: Temporary variables are sign that the programmer does not yet fully understand the problem. Programmer would treat temporary variables casually increasing the chances of error.
4. Boolean Variables: Use typical boolean names like Done, Error, Found and Success. Avoid negative names like NotFound or NotDone.
5. Enumerated Types: In naming members of an enumerated type, use group prefix or suffix.
6. Named Constants: The name should represent the abstract entity rather than the constant value it refers to.

The author then provides some points on why, when and how to create naming convention.
The naming conventions provide several benefits:

• No local decisions are required to be taken allowing to concentrate on more important characteristics of the code.
• Reading source code across projects become easier.
• They help in learning code more quickly.
• They reduce name proliferation.
• They compensate for language weaknesses.
• They emphasize relationships among related items.

The author enlists following reasons to have naming conventions:

• When multiple programmers work on a project
• When one programmer hands over a program to another for modification and maintenance
• When program written by one programmer are reviewed by another
• When the program is large in size
• When standard terms and abbreviations are required in coding

The author then provides some naming guidelines for language independent features:

• Global variables should be easily identifiable with g_ prefix.
• Module variables should be easily identifiable with m_ prefix.
• Use a prefix or suffix to identify type definitions.
• Named constants need to be distinguishable from variables.
• Enumerated types should be distinguishable from named constants, variables and functions.
• Input only parameters should be identifiable in languages that don't enforce them.
• Names should be formatted with separators like _ to enhance readability.

The author then provides naming guidelines for languages like C, Pascal and Fortran.
The author then discusses Hungarian Naming Convention for C programming language and shows its advantages and disadvantages.
The author advises not to use short names but still provides some preferred ways to shorten names if need arises. The author recommends not to use phonetic abbreviations for variable names.
The author then provides some rules to avoid traps in creating abbreviations:

• Don't abbreviate by removing just one character.
• Abbreviate consistently across the whole program with the same abbreviation
• Create names that can be pronounced
• Always document short names with translation tables

The author then provides some names to avoid:

• Misleading names and abbreviations
• Names with similar meanings
• Similar Names with different meanings
• Names that sound similar phonetically
  
• Numerals in names
• Misspelled words
• Words that are commonly misspelled
• Names with difference in just capitalization
• Names of standard library routines and language keywords
• Names with hard to read character (e.g. l and I (el and eye), 0 and O (zero and ooh), etc... )