Item 32: Postpone variable definitions as long as possible.

Item 32: Postpone variable definitions as long as possible.
So you subscribe to the C philosophy that variables should be defined at the beginning of a block. Cancel that
subscription! In C++, it's unnecessary, unnatural, and expensive.
Remember that when you define a variable of a type with a constructor or destructor, you incur the cost of
construction when control reaches the variable's definition, and you incur the cost of destruction when the
variable goes out of scope. This means there's a cost associated with unused variables, so you want to avoid
them whenever you can.
Suave and sophisticated in the ways of programming as I know you to be, you're probably thinking you never
define unused variables, so this Item's advice is inapplicable to your tight, lean coding style. You may need to
think again. Consider the following function, which returns an encrypted version of a password, provided the
password is long enough. If the password is too short, the function throws an exception of type logic_error,
which is defined in the standard C++ library (see Item 49):
// this function defines the variable "encrypted" too soon
string encryptPassword(const string& password)
{
string encrypted;
if (password.length() < MINIMUM_PASSWORD_LENGTH) {
throw logic_error("Password is too short");
}
do whatever is necessary to place an encrypted
version of password in encrypted;
return encrypted;
}
The object encrypted isn't completely unused in this function, but it's unused if an exception is thrown. That is,
you'll pay for the construction and destruction of encrypted even if encryptPassword throws an exception (see
also Item M15). As a result, you're better off postponing encrypted's definition until you know you'll need it:
// this function postpones "encrypted"'s definition until
// it's truly necessary
string encryptPassword(const string& password)
{
if (password.length() < MINIMUM_PASSWORD_LENGTH) {
throw logic_error("Password is too short");
}
string encrypted;
do whatever is necessary to place an encrypted
version of password in encrypted;
return encrypted;
}
This code still isn't as tight as it might be, because encrypted is defined without any initialization arguments.
That means its default constructor will be used. In many cases, the first thing you'll do to an object is give it
some value, often via an assignment. Item 12 explains why default-constructing an object and then assigning to it
is a lot less efficient than initializing it with the value you really want it to have. That analysis applies here, too.
For example, suppose the hard part of encryptPassword is performed in this function:
void encrypt(string& s);
// encrypts s in place
Then encryptPassword could be implemented like this, though it wouldn't be the best way to do it:
// this function postpones "encrypted"'s definition until
// it's necessary, but it's still needlessly inefficient
string encryptPassword(const string& password)
{
...
// check length as above
string encrypted;
encrypted = password;
encrypt(encrypted);
return encrypted;
// default-construct encrypted
// assign to encrypted
}
A preferable approach is to initialize encrypted with password, thus skipping the (pointless) default
construction:
// finally, the best way to define and initialize encrypted
string encryptPassword(const string& password)
{
...
// check length
string encrypted(password);
// define and initialize
// via copy constructor
encrypt(encrypted);
return encrypted;
}
This suggests the real meaning of "as long as possible" in this Item's title. Not only should you postpone a
variable's definition until right before you have to use the variable, you should try to postpone the definition until
you have initialization arguments for it. By doing so, you avoid not only constructing and destructing unneeded
objects, you also avoid pointless default constructions. Further, you help document the purpose of variables by
initializing them in contexts in which their meaning is clear. Remember how in C you're encouraged to put a
short comment after each variable definition to explain what the variable will eventually be used for? Well,
combine decent variable names (see also Item 28) with contextually meaningful initialization arguments, and you
have every programmer's dream: a solid argument for eliminating some comments.
By postponing variable definitions, you improve program efficiency, increase program clarity, and reduce the
need to document variable meanings. It looks like it's time to kiss those block-opening variable definitions
good-bye.