就我个人而言，我无法忍受区域标签，但显然它们对组织代码具有广泛的吸引力，所以我想测试水的温度，以供其他 MS 开发人员接受这个想法。
我个人的感觉是，任何简化代码的愚蠢技巧只会助长糟糕的编码行为，例如缺乏凝聚力、意图不明确以及编码标准差或不完整。
一位程序员告诉我，代码区域通过明确其他程序员应该将他或她的贡献放在哪里来帮助鼓励编码标准。
但是，坦率地说，这对我来说听起来像是一大堆马粪。如果您有一个标准，那么程序员的工作就是了解该标准是什么……您不需要在每个单独的类文件中定义它。
而且，没有什么比打开文件时所有代码都折叠更烦人的了。我知道 cntrl + M, L 将打开所有内容，但是您需要阅读可怕的“哈希区域定义”打开和关闭行。
他们只是烦人。
我最坚定的快速编码理念是所有程序员都应该努力创建清晰、简洁和有凝聚力的代码。区域标签只是用来制造噪音和多余的意图。
区域标签在经过深思熟虑和有目的的课程中没有实际意义。
它们似乎对我有意义的唯一地方是自动生成的代码，因为您永远不必出于个人好奇心而阅读它。
我喜欢区域，并且一直使用它们。我用它们在类内对同类成员进行分组。
您已经可以在编辑器中折叠方法、类和命名空间。区域为您提供了创建另一个级别的选项，使您可以按照您认为重要的方式排列代码。
SA1124：不使用区域
原因
C# 代码包含一个区域。
规则说明
只要将区域放置在代码中的任何位置，就会违反此规则。在包括 Visual Studio 在内的许多编辑器中，默认情况下该区域将显示为折叠状态，从而隐藏该区域内的代码。隐藏代码通常是一种不好的做法，因为随着代码的长期维护，这可能会导致错误的决策。
如何解决违规问题
要修复违反此规则的行为，请从代码中删除该区域。
关于这是否是一个合理的规则存在一些讨论。
共识似乎是有些人喜欢地区而有些人不喜欢——这取决于各个团队来决定。最重要的是在整个项目中使用一致的风格。
可以接受区域的一个地方是将实现特定接口的所有方法分组。值得注意的是，如果您使用代码生成功能提供用于实现接口的方法存根，Visual Studio 会自动添加一个区域。
它们似乎对我有意义的唯一地方是自动生成的代码，因为您永远不必出于个人好奇心而阅读它。
部分类功能更适合将自动生成的代码与同一类中的手动生成的代码分开。
使用自动生成的源代码时，可以将代码添加到类中，而无需重新创建源文件。Visual Studio 在创建 Windows 窗体、Web 服务包装代码等时使用此方法。您可以创建使用这些类的代码，而无需修改由 Visual Studio 创建的文件。
我认为这#region完全没问题。我自己从未使用过它，但如果您有一个大型或复杂的课程，它可以帮助您找到所需的内容。想象一下，如果您正在实施 ID3D10Device1- 有一百多种方法要实施。你想把它们都扔在一个地方吗？
我确实使用区域来组织一个类中更大的结构，即。一个带有回调和方法的依赖属性被调用，例如。你有一个 DP，IEnumerable<T>你想使用弱事件模式来响应INotifyCollectionChanged。这可能需要一些代码，并且在编码后我不会触摸它，所以我将它放在一个区域中。
但是，如果您使用区域来构建您的逻辑，这是严重的代码异味，这就是 Mark 帖子中的 StyleCop 规则所指的。
当我在编程时，我经常使用区域，它们帮助我保持我的代码井井有条，并且能够只专注于我关心的部分。我总是在这些地区添加评论以及它们是关于什么的。但是当我完成时，我总是删除它们。它是一个方便的工具，仅此而已。
IHMO，如果你#region在一个类中有部分，这意味着你在你的类中有两个行为，所以你应该把你的类分成两个对象。