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?