I love reading the book Code Complete, by Steve McConnell. The following comes from it, in its Chapter 10: General issues in using variables.
……….
“Scope” is a way of thinking about a variable’s celebrity status: how famous is it?
Scope, or visibility, refers to the extent to which your variables are known and can be referenced throughout a program. A variable with limited or small scope is known in only a small area of a program- a loop index used in only one small loop, for instance. A variable with large scope is known in many places in a program- a table of employee information that’s used throughout a program, for instance.

Different languages handle scope in different ways. In some primitive languages, all variable are global. You therefore don’t have any control over the scope of a variable, and that can create a lot of problems. In C++ and similar languages, a variable can be visible to a block (a section of code enclosed in curly brackets), a routine, a class (and possibly its derived classes), or the whole program. In Java and C#, a variable can also be visible to a package or namespace (a collection of classes).

Keep Variables “Live” for as Short a Time as Possible
A concept that’s related to variable span is variable “live time”, the total number of statements over which a variable is live. A variable’s life begins at the first statement in which it’s referenced; its life ends at the last statement in which it’s referenced.

Unlike span, live time isn’t affected by how many times the variable is used between the first and last times it’s referenced. If the variable is first referenced on line 1 and last referenced on line 25, it has a live time of 25 statements. If those are the only two lines in which it’s used, it has an average span of 23 statements. If the variable were used on very line from line 1 through line 25, it would have an average span of 0 statements, but it would still have a live time of 25 statements.

As with span, the goal with respect to live time is to keep the number low, to keep a variable live for as short a time as possible. And as with span, the basic advantage of maintaining a low number is that it reduces the window of vulnerability. You reduce the chance of incorrectly or inadvertently altering a variable between the places in which you intend to alter it.

A second advantage of keeping the live time short is that it gives you an accurate picture of your code. If a variable is assigned a value in line 10 and not used again until line 45, the very space between the two references implies that the variable is used between lines 10 and 45. If the variable is assigned a value in line 44 and used in line 45, no other uses of the variable are implied, and you can concentrate on a smaller section of code when you’re thinking about that variable.

A short live time also reduces the chance of initialization errors. As you modify a program, straight-line codes tends to turn into loops and you tend to forget initializations that were made far away from the loop. By keeping the initialization code and the loop code closer together, you reduce the chance that modifications will introduce initialization errors.

A short live time makes your code more readable. The fewer lines of code a reader has to keep in mind at once, the easier your code is to understand. Likewise, the shorter the live time, the less code you have to keep on your screen when you want to see all the references to a variable during editing and debugging.

Finally, short live times are useful when splitting a large routine into small routines. If references to variables are kept close together, it’s easier to refactor related sections of code into routines of their own.