Parameter vs. Member variables

Question

I\'ve recently been working with someone else\'s code and I realized that this individual has a very different philosophy regarding private variables and method parameters t

Answer 1

You should only create variables when and where they are needed, and dispose of them when you are done. If the class doesn't need a class level variable to function, then it just doesn't need one. Creating variables where you don't need them is very bad practice.

Answer 2

I would disagree with implementing it for global access or to make programming easier. By exposing these globally without filtering of any kind make it more difficult to determine access in the future.

Answer 3

I'm not sure there is a stated best-practice for using globally scoped variables versus always passing as method parameters. (By "private variables", I'm assuming you mean globally scoped variables.)

Using a globally scoped variable is the only way to implement properties in .NET (even automatic properties ultimately use a globally scoped variable, just not one you have to declare yourself).

There is a line of arguement for always using method parameters because it makes it completely clear where the value is coming from. I don't think it really helps prevent the method from making changes to the underlying value and it can, in my opinion, make things more difficult to read at times.

Answer 4

Since object properties are meant to hold state, as stated by the others, my policy is to have all of them private by default unless I have a good reason to expose them.

It's much easier to make them public later on, if you have to, simply by writing a getter method for example (which i also don't have to think about right at the beginning of writing a class). But reeling in a public property later on may require a huge amount of code to be re-written.

I like to keep it flexible while not having to think about this more than needed.

Answer 5

I claim that it isn't a style issue but rather a readability/maintainability issue. One variable should have one use, and one use only. “Recycling” variables for different purposes just because they happen to require the same type doesn't make any sense.

From your description it sounds as if the other person's code you worked on does exactly this, since all other uses are basically covered by your list. Put simply, it uses private member variables to act as temporaries depending on situation. Am I right to assume this? If so, the code is horrible.

The smaller the lexical scope and lifetime of any given variable, the less possiblity of erroneous use and the better for resource disposal.

Answer 6

I think the answer is straightforward if you are familiar with C++ destructors. All member variables should be assigned a way to be destructed while function parameters are not. So that's why member variables are usually the states or dependicies of an object having some kind of relation regarding their lifecycle.