putting the same local variable into a member variable

[lianqtlit]

lets say there are 3 int ncount variable in every method

private void x_method1()
{
int ncount = dv.length;
}

private void x_method2()
{
int ncount = drarr.length;
}

private void x_method3()
{
int ncount = dr.length;
}

Is it best to do this? and why?

int m_ncount;

private void x_method1()
{
m_ncount = dv.length;
}

private void x_method2()
{
m_ncount= drarr.length;
}

private void x_method3()
{
m_ncount= dr.length;
}

 

[Peter Duniho]

lets say there are 3 int ncount variable in every method

private void x_method1()
{
int ncount = dv.length;
}

private void x_method2()
{
int ncount = drarr.length;
}

private void x_method3()
{
int ncount = dr.length;
}

Is it best to do this? and why?
[...]

When you say "this", to which example of code are you referring? The one
I quoted? Or the example I left out?

The only reason to put the variable into the class as an instance member
is if it's a value that needs to be accessed by other members in the class
and it would be unavailable otherwise.

In the example you provided, as near as I can tell there's no relationship
between the three different uses of the variable, other than the fact that
it's always a length of something. If the variable was working fine as a
local variable already, then absent any other information I'd say it
should continue to work fine as a local variable and there's no need to
change it to an instance member. It would, in fact, be kind of silly to
do so.

Pete

 

[Marc Gravell]

Well, the first set don't really do anything long-term: local
variables[*] only live for the duration of the method (they live on
the stack). It isn't clear what you want to do; but /if/ you want all
three methods to update the same field (instance variable), then yes:
the second set of examples illustrate /a/ way to do this...

There may be tidier ways of doing things, but it is hard to say
without more information.

[*=excluding "captured variables"]

Marc

 

[Jon Skeet [C# MVP]]

On Dec 18, 7:49 am, lianqtlit <[email protected]>
wrote:

Is it best to do this? and why?

int m_ncount;

<snip>

Don't make something a member variable just to stop you from having to
declare it in a number of methods. What you should ask yourself is
whether it's naturally a piece of data about the instance. If it is,
it's logical to make it a member variable - otherwise, don't.

Jon

 

[lianqtlit]

It is the example you left out.
thanks for your reply

lets say there are 3 int ncount variable in every method

private void x_method1()
{
int ncount = dv.length;
}

private void x_method2()
{
int ncount = drarr.length;
}

private void x_method3()
{
int ncount = dr.length;
}

Is it best to do this? and why?
[...]

When you say "this", to which example of code are you referring? The one
I quoted? Or the example I left out?

The only reason to put the variable into the class as an instance member
is if it's a value that needs to be accessed by other members in the class
and it would be unavailable otherwise.

In the example you provided, as near as I can tell there's no relationship
between the three different uses of the variable, other than the fact that
it's always a length of something. If the variable was working fine as a
local variable already, then absent any other information I'd say it
should continue to work fine as a local variable and there's no need to
change it to an instance member. It would, in fact, be kind of silly to
do so.

Pete

 

[lianqtlit]

oh.. I see thanks..

On Dec 18, 7:49 am, lianqtlit <[email protected]>
wrote:



<snip>

Don't make something a member variable just to stop you from having to
declare it in a number of methods. What you should ask yourself is
whether it's naturally a piece of data about the instance. If it is,
it's logical to make it a member variable - otherwise, don't.

Jon

 

[Jon Skeet [C# MVP]]

Well, the first set don't really do anything long-term: local
variables[*] only live for the duration of the method (they live on
the stack). It isn't clear what you want to do; but /if/ you want all
three methods to update the same field (instance variable), then yes:
the second set of examples illustrate /a/ way to do this...

There may be tidier ways of doing things, but it is hard to say
without more information.

[*=excluding "captured variables"]

And local variables in iterator blocks

(I normally forget those myself, but I've just been revising chapter
5...)