StyleCop SA1124 DoNotUseRegions合理吗？

Question

SA1124 DoNotUseRegions建议不要在任何地方使用该区域.这真的合理吗？

我认为region是一种将相关代码组合在一起并使大类易于阅读的方法,例如,如果通过上下文菜单为vs2008中的类生成接口方法,则会自动插入一个区域.

我想在检查代码样式时删除此规则.我可否知道你对这条规则的看法？

Answer 1

在编写良好的代码中不再需要区域.它曾经对隐藏机器生成的代码很有用.现在代码进入一个单独的文件.区域仍可用于隐藏编写不良的代码.

Answer 2

这将是个人偏好的事情.这里唯一重要的是你和你的团队喜欢什么.忘记警察所说的风格,你是那些阅读它的人,你是那个人在维护它,无论是否有区域对你更好,这一切都很重要.

如果你将它作为一个开源项目发布...... 这是我的观点,我认为同样适用.使用核心团队更熟悉的任何内容.如果你有更多的团队成员和更多的贡献,稍后重新访问该问题,这总是可以改变.

Answer 3

我认为区域可能被滥用,但它们是一种有用的技术,允许读者一次关注代码的某些区域.

但是,我会避免太多的嵌套.

Answer 4

我喜欢区域和我的团队，我觉得代码对它们更易读。

这是我爱他们的时候...

如果您有公司标准来编写带有Arrange Act Assert（AAA）的单元测试，则可以要求单元测试如下所示

[test]
public void MyFunction_Test
{
#region Arrange
#endregion    

#region Act
#endregion

#region Assert
#endregion
}

我真的很喜欢这种格式，特别是当存在清晰的分隔符时，这样做会激发其他人正确地执行某些操作，例如正确地编写单元测试。

我喜欢的另一个地方是代码，当您知道即将删除代码时。

#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完成，您可以转换地区分为不同的类别。