Delay your variable definitions until as late as possible, if they're only needed inside of an if statement for example then declare them inside of the if statement's body, this way, if the if statement evaluates to false then the objects are not created, saving time and memory.
For me, the first one, declaring all variables all at once makes your program neat and easy to understand, if you not properly manage your code you end up a lot of problems later.
If you delay declaration you cannot use an uninitialized value:
1 2 3 4 5 6 7 8 9 10
bool a;
//...
if (a) //oops. Used "a" before defined! Intended as a random generator?
{
//...
}
//...
a = true ; // you intend to use "a" from here on
If you define close to first usage:
1 2 3 4 5 6 7 8 9 10
//bool a;
//...
if (a) //oops. Used "a" before defined declared! => Compile time error!
{
//...
}
//...
bool a = true ; // you intend to use "a" from here on
Other reasons to define a variable close to use:
* if used inside a block, it limits access to this variable (remember: grant access to a variable to the least extend possible; that's why you should use globally defined variables sparingly)
* if used in an inner block, resources get also released earlier
* You don't have uninitialized values.
Declaring all variables in the first lines is a relict from C. Don't do it.
I think that it depends, and you should just learn which one is better on your own. On a case by case basis.
If you write a very complicated long function, which demands sparsely located definitions, then I think you are in need of re-factoring. Functions should be shorter and neater in which case the access to a variable is almost always immediately after the definition.
It is true that definition and initialization should not be separate. This is devious code and calls for errors.
As for performance - it is nowhere near obvious which approach is better. For user types with complicated construction process, placing the definition in one of the program's branches can save time. Sometimes it is even necessary, if there is a side effect from the constructor. For POD types, it is not really worth it. This way, a dumb compiler may end up allocating stack space incrementally instead of at once. If it is optimizing, then it will probably allocate the stack space in one go and perform initialization when the definition is reached, but memory efficiency will be the same as without nested blocks.
I am saying that readability and clarity are your top priority, and there is no silver bullet there. So, if you keep your functions simple and make all initializations at the beginning, I claim you wont go wrong. Try to not ever separate the initialization and the definition by code, though, as the others also advised. And if you think that the function has two parts that are logically separate, like two cases of some algorithm, then sure, use variable definitions for each case.
(This is a bit like the debate on whether you should have more than one exit point from a block of code. Like mid-function return-s, or mid-loop break-s. The advice is that you shouldn't (; according to the principles of structured programming). But make the code intelligible and piece-wise simple, and the rest is generally a secondary issue.)