StyleCop SA1124 DoNotUseRegions合理吗？
SA1124 DoNotUseRegions建议不要在任何地方使用该区域。 这真的合理吗？
我认为region是一种将相关代码组合在一起并使大类易于阅读的方法，例如，如果通过上下文菜单为vs2008中的类生成接口方法，则会自动插入一个区域。
我想在检查代码样式时删除此规则。 我可否知道你对这条规则的看法？
这将是个人偏好的事情。 这里唯一重要的是你和你的团队喜欢什么 。 忘记警察所说的风格，你是那些阅读它的人，你是那个人在维护它，无论是否有区域对你更好，这一切都很重要。
如果你将它作为一个开源项目发布…… 这是我的观点 ，我认为同样适用。 使用核心团队更舒适的任何内容。 如果您有更多的团队成员和更多的贡献，稍后重新访问该问题，这可以随时更改。
在编写良好的代码中不再需要区域。 它曾经对隐藏机器生成的代码很有用。 现在代码进入一个单独的文件。 区域仍可用于隐藏编写不良的代码。
我认为区域可能被滥用，但它们是一种有用的技术，允许读者一次关注代码的某些区域。
但是，我会避免太多的嵌套。
根据我的经验，他们根本不应该被使用。 初级开发人员倾向于滥用它们并创建过于复杂的类，其复杂性被“巧妙地”隐藏在众多区域之后。
在我看来，＃region / #endregion有一个例外 ：实现接口时！
例如
#region Implementation of IDisposable public void Dispose() { // implementation here ... } #endregion
在所有其他情况下，您不应该使用#region，因为它们已经过时（我假设为隐藏生成的代码而创建的地方 – .net-1.0和.net-1.1但现在有部分类）
–Harald-RenéFlasch（又名hfrmobile）
我喜欢地区和我的团队，我觉得代码更易读。
以下是我爱他们的时候……
如果您有使用Arrange Act Assert（AAA）编写unit testing的公司标准，那么您可以要求unit testing如下所示
[test] public void MyFunction_Test { #region Arrange #endregion #region Act #endregion #region Assert #endregion }
我真的很喜欢这种格式，特别是当有明显的分色并且这样做可以激励其他人正确地做某些事情，例如正确地编写unit testing。
我喜欢区域的另一个地方是代码，当你知道你将很快删除代码时。
#region Drop this region next version when we drop 2003 support public void DoSomeThingWithWindowsServer2003() { // code the is for Windows 2003 only } #endregion
我也使用区域来分隔我的类的不同部分，即使该类非常小。
#region Constructors #endregion #region Properties #endregion #region Events #endregion #region Methods #endregion #region Enums #endregion
通常一个类不会拥有所有这些（如果它你可能想知道你是否在一个类中做了太多）但我认为如果你正在寻找一个单一的方法或属性，那么拥有一个单独的地方是很好的看。 更不用说使用INotifyPropertyChanged的ViewModel（MVVM任何人？）中的属性是10行（9行加一个空格），所以设计良好且编写良好的ViewModel对象只有5个属性，意味着属性部分至少为50行代码
当使用其他人写得不好的代码时，我也特别喜欢它们。 假设你总能重构使用完美的设计是愚蠢的。 例如，您有一个2500行或更多的类。 当然这可能写得更好但是你没有这样做，它有效，而且经过测试，你的企业的代码只有“仅修复”锁定，所以不允许进行重构。 你可以使用#region语句创建一个过大的类（写得不好或不可写）。 你可以获得很多关注点分离的可读性好处而不会实际分离类，然后一旦代码失效并且你可以重构，大部分分离工作可能已经使用#regions完成，你可以转换你的区域分为不同的类。
我想知道这条规则是否是其他更普遍接受的规则的副作用，例如私人/受保护/公共成员的订购。 遵循这些排序规则在许多情况下必然会破坏#regions的逻辑分组，因此它们将成为互斥的。