Visual Studio region
Visual Studio has a really nice region feature which allows you to mark off sections of a file so they can be collapsed in the editor.
Now it seems that at Microsoft, there is a growing tendency to group absolutely everything in a class up into groups such as:
Public methods
Public properties
Protected methods
Private methods
Events
Private data
And many developers who see this then go about implementing this in their own code, removing any regions already defined and moving things into new regions based on their accessibility.
But here is the issue I have. How useful an organization is this really? I like it when a class has all of its private data together (I prefer at the top, but some put this at the bottom), so that is fine. And it makes sense for the constructors to be kept together.
But grouping methods by whether they are private, protected or public makes about as much sense as organizing your house by putting all the tables in one room and all the chairs in another. Yes its very organized, and yes you will know exactly where to go when you want a chair, but its not much use when you want to sit down at the table and eat dinner.
Say I'm looking at some code and I see a call to a CalculateOffsets function. How should I know whether I will find it in the public, private or protected methods region?
Surely it makes more sense to group functions into regions by whatever logic the class does. A good example would be a region for the Dispose pattern which includes a public method, a protected method and a finalizer. Another example would be the implementation of an interface such as IComparable. In a Windows forms class, you might have a region that had event handlers for all controls on the form, or a region for just for dealing with one particularly complex control's events.
I'm not saying that the Microsoft way doesn't have benefits or should never be used. But its the one-size-fits-all approach that bothers me. I don't want to expand eight regions every time I open a file only to find most of them are empty or just have one item in each.
#region Painting Functions
... code goes here
#endregion
... code goes here
#endregion
Now it seems that at Microsoft, there is a growing tendency to group absolutely everything in a class up into groups such as:
Public methods
Public properties
Protected methods
Private methods
Events
Private data
And many developers who see this then go about implementing this in their own code, removing any regions already defined and moving things into new regions based on their accessibility.
But here is the issue I have. How useful an organization is this really? I like it when a class has all of its private data together (I prefer at the top, but some put this at the bottom), so that is fine. And it makes sense for the constructors to be kept together.
But grouping methods by whether they are private, protected or public makes about as much sense as organizing your house by putting all the tables in one room and all the chairs in another. Yes its very organized, and yes you will know exactly where to go when you want a chair, but its not much use when you want to sit down at the table and eat dinner.
Say I'm looking at some code and I see a call to a CalculateOffsets function. How should I know whether I will find it in the public, private or protected methods region?
Surely it makes more sense to group functions into regions by whatever logic the class does. A good example would be a region for the Dispose pattern which includes a public method, a protected method and a finalizer. Another example would be the implementation of an interface such as IComparable. In a Windows forms class, you might have a region that had event handlers for all controls on the form, or a region for just for dealing with one particularly complex control's events.
I'm not saying that the Microsoft way doesn't have benefits or should never be used. But its the one-size-fits-all approach that bothers me. I don't want to expand eight regions every time I open a file only to find most of them are empty or just have one item in each.
No comments: