The document discusses best practices for naming variables. It recommends initializing variables as they are declared, giving variables descriptive names to indicate their purpose, and adopting naming conventions to make code more consistent and readable for multiple programmers. Standardized prefixes and abbreviations can make long names more compact while retaining clarity. Overall, the goal is to use variable names that are meaningful, unambiguous, and help convey the essential logic of the code at a glance.

1. Variables
1

2.  General Issues in Using Variables:
 Guidelines for Initializing Variables.
 Scope
 Persistence.
 Binding time.
 Using each variable for exactly one purpose.
 Variables declaration.
2

3.  The Power of Variable Names:
 Considerations in choosing good names.
 The power of naming conventions.
 Informal naming conventions.
 Standardized prefixes.
 Creating short names that are Readable.
 Kinds of names to avoid.
3

4. General Issues in Using Variables
4

5.  Improper initialization problem.
 Reasons:
 The variable has never been assigned a value.
 Part of the variable has been assigned a value and part has
not.
 The value in the variable is outdated .
5

6.  Solutions:
 Initialize each variable as it's declared.
 Use const when possible.
 Pay attention to counters and accumulators.
 Initialize a class's member data in its constructor.
 Check the need for re-initialization.
 Take advantage of your compiler's warning messages
 Check input parameters for validity .
 Use a memory-access checker to check for bad pointers.
 Initialize working memory at the beginning of your program.
6

7.  Scope is variable visibility.
 We can measure scope by:
 Live time.
 Span.
7

8.  live time is total number of statements over which a
variable is live .
1 int recordIndex = 0;
2 bool done = false;
...
...
26 while ( recordIndex < 10)
{...}
64 while ( !done )
{ ... }
1 int recordIndex = 0;
2 while ( recordIndex < 10)
{...}
...
...
63 bool done = false;
64 while ( !done )
{ ... }
8

9.  Why we try to restrict live time?
 You can concentrate on a smaller section of code.
 Code more readable.
 reduces the chance of initialization errors .
 Easy to modify.
9

10.  Span is how you keep variable references close.
1.
2.
3.
4.
1.
2.
3.
4.
a = 0;
a++;
a+= 10;
a = 3;
Life time = (4-1 +1) = 4
Average span = (0+0+0)/3 = 0;
a = 0;
b= 1;
c = 0;
a = b + c;
Life time = (4-1 +1) = 4
Average span = 2/1 = 2;
10

11. 11

12.  Initialize variables used in a loop immediately




before the loop .
Don't assign a value to a variable until just before
the value is used.
Break groups of related statements into separate
routines .
Begin with most restricted visibility, and expand
the scope if necessary .
Keep both span and live time as short as you can.
12

13.  Persistence is life span of a piece of data .
 Problem:
When you assume variable is persist but it's not .
 Solution:
 Set variables to "unreasonable values" when they doesn’t
persist.
 Use assertions to check critical variables.
 Declare and Initialize all data right before it's used.
13

14.  The time at which the variable and its value are
bound.
titleBar.color = 0xFF;
titleBar.color = TITLE_BAR_COLOR;
titleBar.color = ReadTitleBarColor( )
Code-Writing Time
Compile Time
Run Time
The later you bind, the more flexibility you get and
the higher complexity you need .
14

15.  Use each variable for one purpose only.
// Compute roots of a quadratic equation
temp = Sqrt( b*b - 4*a*c );
root[0] = ( -b + temp ) / ( 2 * a );
root[1] = ( -b - temp ) / ( 2 * a );
...
// swap the roots
temp = root[0];
root[0] = root[1];
root[1] = temp ;
Creating unique variables for each purpose makes code more
readable.
15

16.  Avoid hybrid coupling.
Double use is clear to you but it won't be to someone else.
 Make sure all declared variables are used.
16

17. Initializing Variables
 Does each routine check input parameters for validity?
 Does the code declare variables close to where they're first
used?
 Does the code initialize variables as they're declared, if
possible?
 Are counters and accumulators initialized properly and, if
necessary, reinitialized each time they are used?
 Does the code compile with no warnings from the compiler?
17

18. Other General Issues in Using Data
 Do all variables have the smallest lift time possible?
 Are references to variables as close together as possible?
 Are all the declared variables being used?
 Are all variables bound with balance between the
flexibility and the complexity associated?
 Does each variable have only one purpose?
 Is each variable's meaning explicit, with no hidden
meanings?
18

19. The Power of Variable Names
19

20. x = x - xx;
xxx = fido + SalesTax( fido );
x = x + LateFee( x1, x ) + xxx;
x = x + Interest( x1, x );
balance = balance - lastPayment;
monthlyTotal = newPurchases + SalesTax( newPurchases );
balance = balance + LateFee( customerID, balance ) +
monthlyTotal;
balance = balance + Interest( customerID, balance );
A good variable name is readable, memorable, and
appropriate .
20

21.  The Most Important Naming Consideration:
 Good name is to state what the variable represents.
 Optimum Name Length.
Don’t be maximumNumberOfPointsInModernOlympics or np But
be teamPointsMax
21

22.  Are short names always bad?
 Common Opposites in Variable Names.
 maxPoints OR pointsMax OR both ?
 Avoid the confusion between maxPoints and
pointsMax .
 The most significant part of the variable name is at the
front.
22

23.  loop variables:
 Don’t use i, j, and k if:
1. variable is to be used outside the loop.
2. the loop is longer than a few lines.
3. you write nested loops.
Try to avoid altogether .
Code is so often changed, expanded, and copied
into other programs.
23

24.  Naming Status Variables:
 A flag should never have flag in its name .
 Use constants and enumerator for its value.
reportType == ReportType_Annual is more meaningful
than reportflag == 0x80 .
 Naming Temporary Variables:
 Use descriptive variable name instead of temp.
24

25.  Naming Boolean Variables:
 Give Boolean variables names that imply true or false.
(done , error ,found ,success)
 Don’t use negative boolean variable names .
(if not notFound)
 Naming Enumerated Types:
 Using group prefix if your language doesn’t support.
Enum Color {Color_Red , Color_Green }
 enum type itself can include prefix (enColor).
25

26.  When Should Have a Naming Convention
 When multiple programmers are working on a project
 When you plan t turn a program over to another
programmer
 When programs are reviewed by other programmers
 When program is so large that you think about it in
pieces
 When the program will be long-lived enough
26

27.  Why we Have Conventions?
 One global decision rather than many local ones .
 They help you transfer knowledge across projects.
 They reduce name proliferation.
 They compensate for language weaknesses.
 You work with a consistent code.
27

28.  Differentiate between classes and objects via:
 Initial Capitalization
Widget widget.
 All Caps
WIDGET widget.
 "t_" Prefix for Types
t_Widget Widget.
 More Specific Names for the Variables
Widget employeeWidget .
 Identify member variables.
with an m_ prefix.
28

29.  Identify named constants .
Via uppercase letters.
 Identify elements of enumerated types.
 Use all caps or an e_ or E_ prefix for the name of the type.
 Use a prefix based on the specific type like Color_Red.
 Format names to enhance readability.
CIRCLEPOINTTOTAL is less readable than circlePointTotal or
circle_point_total.
29

30.  Guidelines for Language-Specific Conventions:
 i and j are integer indexes.
 p is a pointer.
 Constants and macros are in ALL_CAPS.
 Class and other types are in MixedUpperAndLowerCase().
 Variable and function names as variableOrRoutineName.
 The underscore is not used as a separator within names, except
for names in all caps and certain kinds of prefixes
30

31.  As avgSize, maxNum, firsIndex.
 Advantages of Standardized Prefixes:
 Naming conventions advantage +
 You have fewer names to remember.
 Make names more compact.
31

32.  General Abbreviation Guidelines:
 Remove all nonleading vowels (screen becomes scrn).
 Remove and, or, the, and so on.
 Use the first/first few letters of the name.
 Keep the first and last letters of each word.
 Remove useless suffixes—ing, ed, and so on.
 Keep the most noticeable sound in each syllable.
Be sure not to change the meaning of the variable.
32

33. Comments on Abbreviations:
 Don't abbreviate by removing one character from a word.
 Abbreviate consistently.
Num everywhere or No .
 Create names that you can pronounce
Use xPos rather than xPstn.
 Avoid combinations that result in misreading .
Use bEnd/b_Endrather than bend
 Use a thesaurus to resolve naming collisions.
 Document all abbreviations in a document.
 A reader of the code might not understand the abbreviation.
 Other programmers might use multiple abbreviations to refer
to the same word.
33

34.  Avoid misleading names or abbreviations.
As FALSE as abb for "Fig and Almond Season.“.
 Avoid names with similar meanings.
As fileNumber and fileIndex .
 Avoid variables with different meanings but similar names.
As clientRecs and clientReps .
 Avoid names that sound similar.
As wrap and rap.
 Avoid numerals in names.
As file1,file2
34

35.  Avoid words that are commonly misspelled in English.
As occassionally, acummulate, and acsend.
 Don't differentiate variable names solely by capitalization.
As count and Count.
 Avoid multiple natural languages
As "color" or "colour”.
35

36. ?
programmers over the lifetime of a system
spend more time reading code than writing
code.
36

37.  Steve McConnell, June 2004, Code Complete: A Practical Handbook of
Software Construction, 2nd edn.
37

38. 38