Who likes #regions in Visual Studio? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

Personally I can't stand region tags, but clearly th开发者_StackOverflow社区ey have wide spread appeal for organizing code, so I want to test the temperature of the water for other MS developer's take on this idea.

My personal feeling is that any sort of silly trick to simplify code only acts to encourage terrible coding behavior, like lack of cohesion, unclear intention and poor or incomplete coding standards.

One programmer told me that code regions helped encourage coding standards by making it clear where another programmer should put his or her contributions.

But, to be blunt, this sounds like a load of horse manure to me. If you have a standard, it is the programmer's job to understand what that standard is... you should't need to define it in every single class file.

And, nothing is more annoying than having all of your code collapsed when you open a file. I know that cntrl + M, L will open everything up, but then you have the hideous "hash region definition" open and closing lines to read.

They're just irritating.

My most stead fast coding philosophy is that all programmer should strive to create clear, concise and cohesive code. Region tags just serve to create noise and redundant intentions.

Region tags would be moot in a well thought out and intentioned class.

The only place they seem to make sense to me, is in automatically generated code, because you should never have to read that outside of personal curiosity.

I like regions, and use them all the time. I use them to group members of the same kind inside classes.

You already have the means to collapse methods, classes and namespaces in the editor. Regions give you an option to create another level that lets you arrange the code in a way that corresponds to what you think is important.

StyleCop doesn't like regions:

SA1124: DoNotUseRegions

Cause

The C# code contains a region.

Rule Description

A violation of this rule occurs whenever a region is placed anywhere within the code. In many editors, including Visual Studio, the region will appear collapsed by default, hiding the code within the region. It is generally a bad practice to hide code, as this can lead to bad decisions as the code is maintained over time.

How to Fix Violations

To fix a violation of this rule, remove the region from the code.

There is some discussion about whether or not this is a reasonable rule.

The consensus seems to be that some people like regions and some people don't - it is up to individual teams to decide. The most important thing is to use a consistent style throughout your project.

One place where regions might be acceptable is to group all the methods that implement a particular interface. It is worth noting that Visual Studio automatically adds a region if you use the code generation feature to provide method stubs for implementing an interface.

The only place they seem to make sense to me, is in automatically generated code, because you should never have to read that outside of personal curiosity.

The partial class feature is better for separating automatically generated code from manually generated code within the same class.

When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when it creates Windows Forms, Web service wrapper code, and so on. You can create code that uses these classes without having to modify the file created by Visual Studio.

I think that #region is perfectly fine. I've never used it myself, but if you have a large or complex class, it can help with finding what you're looking for. Imagine if you're implementing ID3D10Device1- that's over a hundred methods to implement. You want to just throw them all in one place?

I do use regions to organize bigger constructs in a class, ie. a Dependency Property with callback and methods getting called by this, eg. you have a DP that takes an IEnumerable<T>, and you want to use the weak event pattern to respond to INotifyCollectionChanged. This can take some code, and as I won't be touching it after coding it, I put it in a region.

However, if you resort to regions to structure your logic, this is severe code smell and that's what the StyleCop rule in Mark's post is pointing hat.

while I am programming I use regions a lot they help me keeping my code organised and be able to focus only on parts I care. I always add comments on the regions and what are they about .But when I am done I am always removing them. Its a handy tool, that's all.

IHMO, if you have #region section in a class, it means that you have two behaviors in your class and so you should split your class in two objects.