I've been doing a tremendous amount of work with VS2005 lately (and getting all our ducks in a row to set things up to embrace it, this isn't just another software upgrade kids) and noticed something funny that I wanted to ask people about.
Currently we generally follow a standard on how we organize our class code inside. Specifically the ordering of how this appear in a class, adding regions surrounding them, etc. This is our basic layout for a simple class:
public class User
{
#region Fields
private string name;
#endregion
#region Constructors
public User()
{
}
#endregion
#region Accessors
public string Name
{
get { return name; }
set { name = value; }
}
#endregion
#region Methods
#endregion
#region Private Methods
#endregion
}
Generally the meat is in the middle with the public methods. Private methods live down below hidden in a region, fields up top, etc. It basically gives us some organization when jumping around in the code. Grant you these days people use the drop down method list or navigators like ReSharpers.
When using VS2005 you have the option (it's not forced thank god) to create your classes using the Class Designer. Here's our class created with it, all pretty and nice, in the happy new designer:
And here's the code generated behind it:
public class User
{
private string name;
public string Name
{
get { return name; }
set { name = value; }
}
public User()
{
}
}
Notice something huh? The Name field was added first then I decided to add a constructor. So the code follows it the way it was entered in the designer. Even after all that (or if you created the code manually) when you say add a new string field called emailAddress then using the refactoring tools to encapsulate it you get something like this:
private string emailAddress;
public string EmailAddress
{
get
{
return emailAddress;
}
set
{
emailAddress = value;
}
}
So Microsoft chose to group the private field with the public accessor. Sounds kind of sane. 6 of one, half a dozen of another. Just wondering if this is going to bug anyone where the codebase reads differently (at least from an organization point of view) than what they might currently do. Is it time to start changing our code organization efforts to accomodate for this so we don't end up with some code looking one way and some looking the other?