DEV Community

Cover image for Code Complete 2: Variables (Part 3)
Iyvonne Bett
Iyvonne Bett

Posted on • Edited on

Code Complete 2: Variables (Part 3)

Variables are a foundational piece to any programming languages. Declaring variables is probably one of the first things you learn in any language after Hello world!

Chapter 10: General Issues in Using Variables

Guidelines for Initializing Variables

  • Ideally, declare and define each variable close to where it's used, following the principle of proximity.
  • Initialize named constants once; initialize variables with executable code, such as in a Startup() method.
  • Initialize each variable as it’s declared Initializing variables as they’re declared is an inexpensive form of defensive programming.
  • Initialize each variable close to where it’s first used Some languages, including Visual Basic, don’t support initializing variables as they’re declared.
  • Use final or const when possible By declaring a variable to be final in Java or const in C++, you can prevent the variable from being assigned a value after it’s initialized.
  • The final and const keywords are useful for defining class constants, input-only parameters, and any local variables whose values are intended to remain unchanged after initialization.
  • Pay special attention to counters and accumulators The variables i, j, k, sum, and total are often counters or accumulators. A common error is forgetting to reset a counter or an accumulator before the next time it’s used.
  • Initialize a class’s member data in its constructor Just as a routine’s variables should be initialized within each routine, a class’s data should be initialized within its constructor.
  • Check the need for reinitialization- Ask yourself whether the variable will ever need to be reinitialized, either because a loop in the routine uses the variable many times or because the variable retains its value between calls to the routine and needs to be reset between calls.
  • Initialize named constants once; initialize variables with executable code If you’re using variables to emulate named constants, it’s OK to write code that initializes them once, at the beginning of the program.
  • Initialize true variables in executable code close to where they’re used. One of the most common program modifications is to change a routine that was originally called once so that you call it multiple times.
  • Use the compiler setting that automatically initializes all variables If your compiler supports such an option, having the compiler set to automatically initialize all variables is an easy variation on the theme of relying on your compiler.
  • Take advantage of your compiler’s warning messages Many compilers warn you that you’re using an uninitialized variable.

Scope

A span is the number of lines between successive variable uses; live time is the number between its first use and its last.
To help minimize scope, begin with most restricted visibility, and expand the variable's scope only if necessary.

A maximizing scope may make programs easy to write, but a program in which any method can use any variable at any time is harder to understand.

Binding Time
The earlier the binding time, the lower the flexibility and the lower the complexity. So add only as much flexibility as needed.

Using Each Variable for Exactly One Purpose
Use variables for only one purpose; avoid having different values for the variable mean different things (like negative values).
Alt Text

Chapter 11: The Power of Variable Names

Considerations in Choosing Good Names
A good name tends to express the "what" more than the "how."
To avoid numSales versus saleNum confusion, consider variable names like salesTotal, salesCount, and salesIndex.

Naming Specific Types of Data
Intermediate variables do not warrant a name like temp. Such a name may indicate that we aren't sure of their real purposes.
Give boolean variables names that imply true or false, like sourceFileFound or isStatusOk instead of sourceFile and status.

Informal Naming Conventions
Variable names can contain; The variable contents, the kind of data, and the scope or visibility of the variable.

Creating Short Names That Are Readable
When shortening variable names, don't remove just one letter, be consistent, create pronounceable names, and avoid mispronunciation.

Kinds of Names to Avoid
Avoid names with similar meanings, like fileNumber and fileIndex.
Avoid names with different meanings but similar names, like clientRecs and clientReps.

My Key takeaways in this chapter are;

  • Data initialization is prone to errors, so use the initialization techniques described to avoid the problems caused by unexpected initial values.
  • Minimize the scope of each variable. Keep references to a variable close together.
  • Keep it local to a routine or class. Avoid global data.
  • Keep statements that work with the same variables as close together as possible.
  • Early binding tends to limit flexibility but minimize complexity. Late binding tends to increase flexibility but at the price of increased complexity.
  • Use each variable for one and only one purpose. 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 favour read-time convenience over write-time convenience.

Top comments (0)