block scoped variables

[Andy Fish]

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

 

[Adam Maass]

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

 

[xarax]

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.

 

[Chris Uppal]

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