If you find your class getting too big such that you need to hide vast parts of it through regions I propose your class is too complex and should be broken apart.
Someone once said that having a convention like the one above:
Private Fields
Constructors
Class Properties
Event Handlers
etc...
is like setting a table where all the plates are together, all the spoons are together, all the knives are together and all the forks are together.
My take on the #region issue is to put related methods, event definitions, and properties together in one region. However, having to do this at all would indicate a code smell (either your class is too big or does too many things) but this is a good first step into refactoring it into a better class.
Whenever I see regions I think that the code is either generated or in need of re-factoring.
Avoid using them and when you feel the need for them, re-examine what you're doing and try to split your class in to smaller ones. Ultimately this will help with the readability of the application more than using regions will.
Personally I wouldn't recommend making code regions part of your code convention. The main reason being that regions hide code, which could potentially lead to issues like:
Developers might miss some important part of the source code
The average amount of LOC in the same file tends to increase
If you are interested in enforcing a coding style convention in your team, have a look at Microsoft StyleCop. Note that the tool currently only works for C#.
Private Member Variables
Constructor
Public Properties
Private Methods
Public Methods
Events
The reason is because of better organization of code. I work with files that may have over 2000 lines of code and it is very difficult to maintain the code without regions.
I think there is no need in regions. Them are not legible. If you need (think, do you realy need?) an amount code in your class, you can use 'partial' class to split the class logic units.
I think that so long as you're consistent accross your project it doesn't matter too much which order you write them in. Also be very very wary of overusing them (hence the initial link!).
There's nothing worse than finding a closed constructor region which is hiding only one line of code.
I think in the end it's down to personal taste. As I've said, consistency is the key!
Think of them as another form of comments: additional information mixed in with your code, which has no formal checking performed on it. Hence it will likely drift out of date with the code.
So NEVER duplicate in comments or region directives that which is already stated in the code.
Only add extra information.
In particular, using regions to restate the fact that certain members are properties, events, etc. is completely pointless. The most common problem there is that you create a region for "private methods", and then you edit one of them to make it public. Now you have to move it, which means that in a diff with the old version, the simple change is much harder to discern.
As you can see I do use regions for Variables, Construction/Destruction, Properties, Public and Private methods. I often add another sub-region into the private region called events. The order of regions also works fine with StyleCop.
发布评论
评论（10）
我的惯例是不使用它们。
如果你发现你的类变得太大以至于你需要通过区域隐藏它的大部分，我建议你的类太复杂并且应该被分解。
My convention is not to use them.
If you find your class getting too big such that you need to hide vast parts of it through regions I propose your class is too complex and should be broken apart.
有人曾经说过，有一个像上面这样的约定：
就像设置一张桌子，所有盘子都放在一起，所有勺子都放在一起，所有刀都放在一起，所有叉子都放在一起。
我对
#region问题的看法是将相关的方法、事件定义和属性放在一个区域中。然而，必须这样做会表明代码有异味（要么你的类太大，要么做了太多事情），但这是将其重构为更好的类的良好第一步。Someone once said that having a convention like the one above:
is like setting a table where all the plates are together, all the spoons are together, all the knives are together and all the forks are together.
My take on the
#regionissue is to put related methods, event definitions, and properties together in one region. However, having to do this at all would indicate a code smell (either your class is too big or does too many things) but this is a good first step into refactoring it into a better class.每当我看到区域时，我都会认为代码要么已生成，要么需要重构。
避免使用它们，当你觉得需要它们时，重新检查你正在做的事情并尝试将你的班级分成更小的班级。最终，这比使用区域更有利于应用程序的可读性。
Whenever I see regions I think that the code is either generated or in need of re-factoring.
Avoid using them and when you feel the need for them, re-examine what you're doing and try to split your class in to smaller ones. Ultimately this will help with the readability of the application more than using regions will.
就我个人而言，我不建议将代码区域作为代码约定的一部分。主要原因是区域隐藏代码，这可能会导致以下问题：
部分源码
同一文件中的 LOC 数量往往会增加
如果您有兴趣在团队中强制执行编码风格约定，请查看 微软 StyleCop。请注意，该工具目前仅适用于 C#。
Personally I wouldn't recommend making code regions part of your code convention. The main reason being that regions hide code, which could potentially lead to issues like:
part of the source code
amount of LOC in the same file tends to increase
If you are interested in enforcing a coding style convention in your team, have a look at Microsoft StyleCop. Note that the tool currently only works for C#.
我用它来节省屏幕空间，没有别的:)
I use it to save screen real estate, nothing else :)
我使用以下区域：
原因是为了更好地组织代码。
我处理的文件可能有超过 2000 行代码，并且在没有区域的情况下维护代码非常困难。
I use the following regions:
The reason is because of better organization of code.
I work with files that may have over 2000 lines of code and it is very difficult to maintain the code without regions.
我觉得分地区没必要。它们不清晰。
如果您需要（想想，您真的需要吗？）您的类中的大量代码，您可以使用“部分”类来分割类逻辑单元。
I think there is no need in regions. Them are not legible.
If you need (think, do you realy need?) an amount code in your class, you can use 'partial' class to split the class logic units.
您可能对此感兴趣你对 c# 区域说不。
我认为，只要您在整个项目中保持一致，编写它们的顺序并不重要。还要非常警惕过度使用它们（因此是初始链接！）。
没有什么比找到一个只隐藏一行代码的封闭构造函数区域更糟糕的了。
我认为最终还是取决于个人品味。正如我所说，一致性是关键！
You might be interested in this do you say no to c# regions.
I think that so long as you're consistent accross your project it doesn't matter too much which order you write them in. Also be very very wary of overusing them (hence the initial link!).
There's nothing worse than finding a closed constructor region which is hiding only one line of code.
I think in the end it's down to personal taste. As I've said, consistency is the key!
将它们视为另一种形式的注释：与代码混合的附加信息，没有对其执行正式检查。因此，它可能会随着代码的变化而过时。
因此，切勿在注释或区域指令中重复代码中已声明的内容。
仅添加额外信息。
特别是，使用区域来重申某些成员是属性、事件等的事实是完全没有意义的。最常见的问题是您为“私有方法”创建一个区域，然后编辑其中一个区域以将其公开。现在你必须移动它，这意味着在与旧版本的差异中，简单的更改更难以辨别。
Think of them as another form of comments: additional information mixed in with your code, which has no formal checking performed on it. Hence it will likely drift out of date with the code.
So NEVER duplicate in comments or region directives that which is already stated in the code.
Only add extra information.
In particular, using regions to restate the fact that certain members are properties, events, etc. is completely pointless. The most common problem there is that you create a region for "private methods", and then you edit one of them to make it public. Now you have to move it, which means that in a diff with the old version, the simple change is much harder to discern.
我为 VS 2008 编写了自己的区域代码片段，我总是使用它：
正如你所看到的，我确实使用了
变量、构造/销毁、属性、公共和区域私有方法。我经常将另一个子区域添加到名为events的私有区域中。区域顺序也适用于 StyleCop。I wrote my own region code snippet for VS 2008 which I always use:
As you can see I do use regions for
Variables,Construction/Destruction,Properties,PublicandPrivatemethods. I often add another sub-region into the private region calledevents. The order of regions also works fine with StyleCop.