代码异味是一种症状，表明设计中存在一个问题，这可能会增加错误的数量：对于区域而言，情况并非如此，但是区域可能会导致产生代码异味，就像长方法一样。
以来：
反模式（或反模式）是在社交或企业运营或软件工程中使用的模式，通常可以使用，但实际上无效和/或适得其反
区域是反模式。他们需要做更多的工作，这些工作不会提高代码的质量或可读性，也不会减少错误的数量，并且可能只会使代码更难以重构。
不要在方法内部使用区域；重构
方法必须简短。如果方法中只有十行，则在处理其他五行时，可能不会使用区域来隐藏其中的五行。
同样，每种方法都只能做一件事情。另一方面，区域旨在分离不同的事物。如果您的方法执行A，然后执行B，则创建两个区域是合乎逻辑的，但这是错误的方法。相反，您应该将方法重构为两个单独的方法。
在这种情况下使用区域也会使重构更加困难。假设您有：
private void DoSomething()
{
var data = LoadData();
#region Work with database
var verification = VerifySomething();
if (!verification)
{
throw new DataCorruptedException();
}
Do(data);
DoSomethingElse(data);
#endregion
#region Audit
var auditEngine = InitializeAuditEngine();
auditEngine.Submit(data);
#endregion
}
使第一个区域崩溃而将注意力集中在第二个区域上不仅有风险：我们可以轻松地忘记阻止流程停止流动的异常（可能有一个带有a的保护子句return，这更加难以发现），而且还会有一个问题如果代码应该以这种方式重构：
private void DoSomething()
{
var data = LoadData();
#region Work with database
var verification = VerifySomething();
var info = DoSomethingElse(data);
if (verification)
{
Do(data);
}
#endregion
#region Audit
var auditEngine = InitializeAuditEngine(info);
auditEngine.Submit(
verification ? new AcceptedDataAudit(data) : new CorruptedDataAudit(data));
#endregion
}
现在，区域没有意义，如果不查看第一个区域中的代码，就不可能阅读和理解第二个区域中的代码。
我有时看到的另一种情况是：
public void DoSomething(string a, int b)
{
#region Validation of arguments
if (a == null)
{
throw new ArgumentNullException("a");
}
if (b <= 0)
{
throw new ArgumentOutOfScopeException("b", ...);
}
#endregion
#region Do real work
...
#endregion
}
当参数验证开始跨越数十个LOC时，很容易使用区域，但是有一种更好的方法来解决此问题：.NET Framework源代码使用的一种方法：
public void DoSomething(string a, int b)
{
if (a == null)
{
throw new ArgumentNullException("a");
}
if (b <= 0)
{
throw new ArgumentOutOfScopeException("b", ...);
}
InternalDoSomething(a, b);
}
private void InternalDoSomething(string a, int b)
{
...
}
不要使用方法以外的区域进行分组
有人用它们将字段，属性等组合在一起。这种方法是错误的：如果您的代码符合StyleCop，则字段，属性，私有方法，构造函数等都已经组合在一起并且很容易找到。如果不是，那么该是时候开始考虑应用确保整个代码库统一的规则了。
其他人则使用区域来隐藏许多相似的实体。例如，当您有一个包含一百个字段的类（如果计算注释和空格，则至少要编写500行代码），您可能会想将这些字段放在一个区域内，将其折叠并忘记它们。再一次，您做错了：在一个类中有这么多字段，您应该更好地考虑使用继承或将对象切成几个对象。
最后，有些人倾向于使用区域将相关的事物组合在一起：事件及其委托，或者与IO相关的方法与与IO相关的其他方法，等等。在第一种情况下，它变得一团糟，难以维护，阅读并理解。在第二种情况下，更好的设计可能是创建多个类。
区域有很好的用途吗？
否。有一个旧用途：生成的代码。尽管如此，代码生成工具只需要使用部分类即可。如果C＃具有区域支持，则主要是因为这种传统用途，并且由于现在有太多人在其代码中使用区域，因此在不破坏现有代码库的情况下就不可能删除它们。
考虑一下goto。语言或IDE支持功能这一事实并不意味着应每天使用该功能。StyleCop SA1124规则很明确：您不应使用区域。决不。
例子
我目前正在对同事的代码进行代码审查。该代码库包含许多区域，并且实际上是如何不使用区域以及区域为何导致不良代码的完美示例。这里有些例子：
4000 LOC怪物：
我最近在Programmers.SE上的某个地方读到，当文件包含太多usings（在执行“删除未使用的用法”命令之后）时，这是一个好兆头，表明该文件中的类做得太多。这同样适用于文件本身的大小。
在查看代码时，我遇到了一个4000 LOC文件。看起来，这段代码的作者只是简单地将同一行的15行方法复制粘贴了数百次，只是略微更改了变量的名称和被调用的方法。一个简单的正则表达式允许通过添加一些泛型将文件从4000 LOC减少到500 LOC。我非常确定，通过更巧妙的重构，此类可以减少到几十行。
通过使用区域，作者鼓励自己忽略该代码无法维护且编写不良的事实，并大量复制代码而不是对其进行重构。
地区“ Do A”，地区“ Do B”：
另一个很好的例子是怪物初始化方法，该方法仅执行任务1，然后执行任务2，然后执行任务3，等等。有五个或六个完全独立的任务，每个任务都在容器类中进行初始化。所有这些任务都被分组为一种方法，并分组为区域。
这有一个优点：
- 通过查看区域名称可以很清楚地理解该方法。话虽如此，重构后的相同方法将与原始方法一样清晰。
另一方面，问题是多方面的：
字段区域，属性区域，构造函数区域：
审阅的代码还包含许多区域，这些区域将所有字段，所有属性组合在一起，等等。这存在一个明显的问题：源代码增长。
当您打开文件并看到巨大的字段列表时，您更倾向于先重构该类，然后再使用代码。在区域中，您习惯于折叠东西而忘却它。
另一个问题是，如果您在所有地方都这样做，则会发现自己创建了一个块区域，这没有任何意义。我所检查的代码实际上就是这种情况，其中#region Constructor包含一个构造函数。
最后，字段，属性，构造函数等应该已经按顺序排列。如果它们是并且它们符合约定（以大写字母开头的常量等），则已经清楚元素类型在何处停止而其他在何处开始，因此您无需为此显式创建区域。