Date Published: June 25, 2020
Code Complete by Steve McConnell is a well-written explanation of themes in software construction.
I'm working my way through the second edition of Code Complete by Steve McConnell. Here are my notes from Part 3: Variables.
Part 3 includes chapters 10-13: General Issues in Using Variables, The Power of Variable Names, Fundamental Data Types, and Unusual Data Types.
Implicit declarations - some languages let you use variables without explicitly declaring them
Uninitialized or improperly initialized variables inevitably cause problems. How to avoid them?
final
or const
when possible for variables whose values should not change after initializationScope/visibility - how extensively a variable is known and can be used in a program
Begin with the most restricted visibility and expand the variable's scope only if necessary
Persistence - how long a piece of data "lives"
Binding time - when a variable and its value are bound together
3 main types of data:
if
or case
statementsfor
, repeat
, and while
structuresEach variable should be used for exactly one purpose
x
and temp
because that implies a relationship that doesn't actually existpageCount
means the number of pages except if it is negative, and then it means there's an error. Variables should mean what their name says they mean, and nothing elseA good name for a variable fully and completely describes what the variable represents
Avoid names that describe how a problem is solved
printerReady
vs bitFlag
or sum
vs calcVal
Variables with smaller scope can usually get away with shorter names
i
in a for
loopWhen working with variables containing values like sums, totals, averages, etc. you should put those qualifiers at the end of a variable name so the more descriptive part is read first
revenueTotal
> totalRevenue
Loop index variables are conventionally named i
, j
, and k
Status variables should never just be named flag
Temporary variables often lead to errors when programmers give them lazy names
Boolean variable names should imply true or false
done
indicates whether something is done; starts falseerror
indicates whether an error has occurred; starts falsefound
indicates whether a value has been found; starts falsesuccess
or ok
indicates whether an action was successfulFor enumerated types, you should use a prefix for all members of the group for clarity
Conventions are really great for purposes of consistency, readability, and compensating for weaknesses within certain languages
Guidelines for informal language-independent conventions
Standardizing prefixes is very helpful and allow for more compact variable names
Abbreviation guidelines (don't use all at once)
ENDB
, not BEND
Fundamental data types are the building blocks of other data types
How to avoid errors with numbers:
3.1415
instead of a variable pi
)When working with integers:
When working with floating-point numbers:
Currency
in Visual Basic)When working with characters and strings:
When working with booleans:
Enumerated types allow each member of a class of objects to be described in English and are used when you know all possible values of a variable
Country_China
, etc., have Country_First = 0
and Country_Last = n
When working with named constants:
When working with arrays:
Some languages allow programmers to create their own types (aka type aliasing)
13. Unusual Data Types
Structure = data built up from other types
Pointers are very complicated and error-prone
Global variables are accessible anywhere in a program
Access routines
Thanks for reading! I hope you find this and other articles here at ilyanaDev helpful! Be sure to follow me on Twitter @ilyanaDev.