Psychological variables and properties

Mar 13, 2007

I’ve noticed that there are two different ways developers locate private variables used by properties. One way is to locate the private variable next to the property that returns them and all other private variable located elsewhere.

#region Private fields

private string _Member;
private int _AnotherMember;

#endregion

#region Properties

private string _Name;
public string Name
{
get { return _Name; }
set { _Name = value; }
}

private int _Age;
public int Age
{
get { return _Age; }
set { _Age = value; }
}

#endregion

The other way is to separate all private variables, both the ones that are used by properties and the ones used by the rest of the class, into two different locations.

#region Private fields

private string _Name;
private int _Age;
private string _Member;
private int _AnotherMember;

#endregion

#region Properties

public string Name
{
get { return _Name; }
set { _Name = value; }
}

public int Age
{
get { return _Age; }
set { _Age = value; }
}

#endregion

There are problems and advantages with both approaches even though they appear minor. It has to do with the psychological difference between variables.

The psychological difference

Let’s say there are two different types of private variables – the ones used by properties and the ones not used by properties. Basically, there is no difference. A private variable is the same no matter how it is used, but the usage is what makes the difference.

A private variable used by a property is a sort of a placeholder that is only accessed through the property. Because of that, it only exists because of the property and can therefore be considered a part of the class’s interface.

A private variable that isn’t used by a property is used by multiple methods in a more interactive manor. It exists because the inner workings of the class needs it and it has nothing to do with the public interface.

The difference is psychological because a private variable is the same no matter how it is used. I don’t think there is a wrong way to do it and it all comes down to personal choice of the developer.

Personally, I use the first approach because I can’t ignore the psychological difference and thinks it makes my code more maintainable and easier to understand. I find it to be difficult to get an overview of a class that has all private variables grouped together, because they don’t tell me anything about how they are used. Then I need to find the references manually in the code and it just seems unnecessary in many cases.

Another thing is that I like to comment the different private variables, but only the ones that are not used by properties. The ones used by properties don't need to be commented because it is obvious what they do, but only if they are located next to their respective property.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

Comments (12) -

Brian
Brian
3/13/2007 6:24:54 PM #

You say you use the second approach, but then you say it is difficult to get an overview that has all private variables grouped together...it looks that that statement conflicts with itself.

Mads Kristensen
Mads Kristensen
3/13/2007 6:29:35 PM #

Oops. You caught me. I made a typo. It is corrected now. Thanks.

Sean Kearney
Sean Kearney
3/13/2007 6:31:35 PM #

I've been using this VS Snippet for some time now. It is a bit better than the standard snippet for a property, plus it has a nice Region around it.
http://www.gotcodesnippets.com/1029.snippet
Check it out!

 Eber Irigoyen
Eber Irigoyen
3/13/2007 7:48:03 PM #

when you have a lot of properties it makes it easier to read/navigate if you group all the fields together and all the properties in a separate section, navigating to the field is just a matter of right click, go to definition

I use both approaches, not picky about that particular thing, like Sean I also use code snippets and many times just leave it like that

 Jason
Jason
3/13/2007 7:59:33 PM #

I agree with you, Mads. I use the same method in my code. Most of my co-workers come from a VB6/VBA background and still put all of their private variables at the top of the class. One-by-one I am convincing them to put property-storage variables right above the actual property for the same psychological reasons you mentioned.

Ciz
Ciz
3/13/2007 9:57:21 PM #

Completely agree, plus "prop" snippet puts the local variable next to the property, and who can be bothered to move it... Smile

Judah
Judah
3/14/2007 1:22:44 PM #

I religiously use the second: it's easy to find all fields in the class without having to search through code.

However, perhaps this is a moot point since C# 3 introduces automatic properties:

public string Foo
{
   { get; } { set; }
}

No explicit field declaration required; the compiler will automatically generate one for you.

 Rob W
Rob W
3/14/2007 10:30:20 PM #

I'm primarily a Java developer, but the same issue exists.  I use an approach closer to your second method, though.

Why?  In short, I want the stuff at the top of the file to be the things I'm work with and edit directly.  The less interesting something is, the less I want to see it.

If I want to get a fast overview of a class, I don't want to have to wade through the get/set method definitions.  Take a class with, say, 50 properties.  In method #2, I put in a comment "//properties" to remind myself which private variables are which, and I can grasp the 50 properties in 51 lines.  With method #1, you'll have to scroll through 350 lines of code to get the same info.

Method #2 is also better at taking advantage of IDE features -- basic get/set methods aren't something I want to code by hand -- or scan past to get to "real" code.  So my accessible properties go together near the top of the file with a comment.  Private variables that are used internally only are just below that (separated off by a comment, and with their own comments if needed).

Then come the "interesting" methods that do real things.  Then I have a comment "just getters/setters below", and use the IDE to generate them for me (it pops a list of instance variables, I check off the getters/setters I want).

And I never have to even look at that code.  If I rename of one of these properties, add a new one, drop one, etc. the IDE updates the getters/setters automatically as part of the refactoring.

If I want to know if a getter/setter exists for a class, again the IDE steps in.  Calling in from another class, code completion either shows it or doesn't.  When editing that class, the outline lists all methods (and I can check at a glance).

-Rob

Mat
Mat
3/15/2007 5:31:05 PM #

It is very useful to look at a class and see what its state variables are.  If these are scattered throughout then you have a maintenance problem.  This could be solved with some future(?) IDE feature like a popup displaying all state variables?!  Until then, my vote is keep them together at the top.

Mads Kristensen
Mads Kristensen
3/15/2007 6:48:20 PM #

Rob, that's a pretty clever way of doing it. To keep all private variable grouped together by keeping the property fields separate from the other private fields and still have them in the same grouping. I haven't thought of that. However, I don't see the point of adding a comment next to each property to tell what private field they use, because the names are almost identical with the exception of an underscore or in lower-case or other similar small differences.

Steve Smith
Steve Smith
3/21/2007 1:43:51 PM #

I agree with your approach (the first one) Mads.  And I put all of the properties at the top generally right after the local variables and constructors (sometimes above the constructors - not always consistent with this).  For folks who don't want to wade through lots of get/set calls, this will be fixed in C# 3 with automatic get/sets but also this is easily fixed with a #region Properties ... #endregion block, which is also standard practice for me.

 David Seruyange
David Seruyange
3/21/2007 9:44:21 PM #

If you've got a lot of properties to churn out, give my utility "proper" a whirl: http://www.t3rse.com/proper

It's a lot faster than the "refactor" options and it is useful for folks who can't afford (or talk their boss into) something like CodeRush.

Comments are closed

About the author

Mads Kristensen

Mads Kristensen
Program Manager at the Microsoft Web Platform team and founder of BlogEngine.NET.

More...

Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.