Hi,

Often when I introduce a new variable declaration in the middle of a block
it is just for temporary purposes, so I would like that variable to go out
of scope when I'm done with it, rather than staying in scope until the end
of the function.

A trick I have occasionally used is to include an artificial inner block
e.g.

....
{
    int workingValue=0;
    ...
}
// now I know workingValue has gone out of scope

do you folks think this is a viable programming practice, or does the
apparently superfluous level of nesting just serve to hamper readability and
confuse people?

Andy

"Andy Fish" <ajfish@blueyonder.co.uk> wrote:
> Hi,
>
> Often when I introduce a new variable declaration in the middle of a block
> it is just for temporary purposes, so I would like that variable to go out
> of scope when I'm done with it, rather than staying in scope until the end
> of the function.
>
> A trick I have occasionally used is to include an artificial inner block
> e.g.
>
> ...
> {
>     int workingValue=0;
>     ...
> }
> // now I know workingValue has gone out of scope
>
> do you folks think this is a viable programming practice, or does the
> apparently superfluous level of nesting just serve to hamper readability
and
> confuse people?
>

Local variables, regardless of block scope, are all allocated on the stack
at the beginning of the method call.


But, if you use multiple block-scoped local variables, then stack slots
might be re-used.

For example:

int a;
char b;

allocates two stack slots. So does:

int a;
// two stack slots exist; one for a, and one for b, coming up.
{
   char b;
   // do something else
}

// b's stack slot is still allocated, and will remain so until
end-of-method.

----------------------------------------------


But

{
   int a;
}

{
   char b;
}

The variables a and b might be able to share a stack slot.


My take on things: don't go cluttering your code with inner blocks just
because local variables go out of scope that much sooner. Unless you first
prove that you have a problem, and that changing your source in this manner
improves your situation. Given the discussion above, using many block-scoped
local variables is unlikely to help unless: 1) You have a method that
requires many, many short-lived variables that is 2) highly recursive. (This
is where a small stack frame might help.)


-- Adam Maass

"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message news:<tG6%a.2461$1Y5.16339107@news-text.cableinet.net>...
> Hi,
> 
> Often when I introduce a new variable declaration in the middle of a block
> it is just for temporary purposes, so I would like that variable to go out
> of scope when I'm done with it, rather than staying in scope until the end
> of the function.
> 
> A trick I have occasionally used is to include an artificial inner block
> e.g.
> 
> ...
> {
>     int workingValue=0;
>     ...
> }
> // now I know workingValue has gone out of scope
> 
> do you folks think this is a viable programming practice, or does the
> apparently superfluous level of nesting just serve to hamper readability and
> confuse people?
> 
> Andy

This is fine. I generally place a //-style comment at the
start of the block, and the same comment at the ending brace
to aid readability (depending on the size of the block).

I generally do not like the usual approach of sprinkling
local variables throughout the same-level block. I prefer
to have them all at the start of the block. However, there
are times when some of the local variables are just too
short-lived to merit such placement. In that case, I simply
open a new block, declare and use the variable, then shut
the block.

Do not worry about such details as reusing stackframe slots,
since that is compiler-dependent. Go for readability and
maintainability. You (and others) will spend far more time
reading the code than writing it.

Andy Fish wrote:

> A trick I have occasionally used is to include an artificial inner
> block e.g.
>
> ...
> {
>     int workingValue=0;
>     ...
> }
> // now I know workingValue has gone out of scope
>

My immediate thought is that if there's enough stuff after workingValue has
gone out of scope for the "trick" to have any value, then I wouldn't
particularly want to work with that code whether the trick is used or not.

    -- chris