Changing the way you code, physically?
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
}
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()
{
}
}
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?