Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > block scoped variables

Reply
Thread Tools

block scoped variables

 
 
Andy Fish
Guest
Posts: n/a
 
      08-15-2003
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


 
Reply With Quote
 
 
 
 
Adam Maass
Guest
Posts: n/a
 
      08-16-2003

"Andy Fish" <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
xarax
Guest
Posts: n/a
 
      08-16-2003
"Andy Fish" <(E-Mail Removed)> wrote in message news:<tG6%a.2461$(E-Mail Removed)>...
> 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.
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      08-16-2003
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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Initial values of File scoped and Block level variables Madhav C Programming 27 01-16-2006 03:29 AM
Initial values of File scoped and Block level variables Madhav C Programming 4 01-08-2006 01:44 PM
Viewing variables within process scoped procedures (Modelsim) Mark VHDL 4 11-09-2004 11:13 PM
Kernel#load and locally scoped variables John Ruby 1 07-09-2004 08:11 PM
Lexically scoped variables Eric Sunshine Ruby 6 12-26-2003 10:55 AM



Advertisments