Should one keenly & consciously attempt to postpone variable definitions as long as possible?

In his book Effective C++ Scott Meyers brings out one interesting guideline,

Item 26: Postpone variable definitions as long as possible. It increases program clarity & improves program efficiency.

The argument he puts forward to support the above is that, whenever a variable is created or destructed we incur some cost for construction & destruction of the variable.

We may have multiple control flows where in we might return from the function without making use of a variable defined early(at the beginning of the function) & thus may unnecessarily incur the cost of creation of the unused variable.

It all seems to be logical, & indeed a good practice. Coming from a c background I 开发者_StackOverflow社区have a tendency of declaring all my variable at the beginning of a function block. Maybe it is merely the c background but I also feel having all declarations at one place in a function provides for easy & better readability.

So the question is how many of you do actually follow such a practice, in day to day programming or it is merely an overkill to attempt to follow such a practice.

Scott Meyers' advice is (as usual) very good and you should follow it. I'm doing this for two decades now, and I don't like the fact that Java has taken to the C way of doing this.

I certainly do. It indeed takes some adaptation to the new habit (coming from other languages myself I know what you mean), but once you're there, it's much more convenient. I see 2 more benefits in addition to what you mention:

1. improved readability: you need less "cache" in your brain to remember the variables used in the function scope. Every small peace of code defines its own variables.

2. initialization: it is a very important principle that variables should be defined initialized whenever possible. It is not always possible to know the initialization value at the beginning of a function

Even in modern C you should postpone declaration until you can initialize with a reasonable value. Scott is the teacher, we are but followers...

The rule has been part of the coding guidelines everywhere I've worked. There are a few exceptions (e.g. if the variable is going to be initialized with input from a stream), but generally, the variable should be defined as close to the point of first use as possible, and defined initialized with a valid value.

I nearly always (except when maintaining existing code for example) delay variable declarations as long as possible. It allows for greater locality of variable scope, which makes understanding the code easier (clearly shows where the variable is used). It allows me to initialize the variable right at the point of declaration instead of leaving it uninitialized or giving it a dummy state. For classes with no default constructor you can't declare them early because you don't know the constructor parameters yet.

I'm going to largely ignore the better readability claim, but I disagree with it. The C89 rule was due to compiler limitations, not for readability (and C99 changed the rule to allow variables to be declared anywhere).

In C there is no cost to declaring uninitialized variables, because all variables are PODs, so you can declare everything at the top of the function and initialize it later. In C++ some types have non-trivial default constructors, so you pay to initialize them immediately, and so it is better to delay doing that until you need them.

Using your C habits as a guide in C++ is not a good idea. The same rules don't apply.

I do both.

What I mean is that, following the guideline from Scott Meyers, I only define variables at the last possible moment. When this means they follow an open brace I take this as a signal that this part of the function might need extracting to its own function. Once the new function is extracted those local variables have been extracted along with it - and they appear at the top of the function.

I usually delay defining a variable until just before it's used, roughly as Scott recommends.

IMO, however, if "where it's needed" is really a lot different from "the beginning of the block" (or even "beginning of the function"), chances are pretty fair that you're writing single functions that are probably larger than ideal, and your code might benefit from being broken up into pieces that are smaller, simpler, and more understandable.

I frequently group my variable definitions logically, rather than defining each as needed. This might mean all at once at the top of the function, or it might not.

As an example, pretend I have a function that calculates three statistics. If two of those statistics require some pre-processing [beyond simple initialization], but the third does not, I will still group all three together at the start of the function, since they are a logical group. But I won't define the random loop conditional that gets used for error checking at the same time, because it has nothing to do with the other three.

Sometimes there are ways to refactor the function to remove such considerations, but sometimes not.

I do this as well. With modern IDEs it's not so helpful but if you have the declaration near where it's used you can see the type without searching.