StyleCop SA1124 DoNotUseRegions 是不是合理？ [关闭]

Posted 2023-02-23

【中文标题】StyleCop SA1124 DoNotUseRegions 是不是合理？ [关闭]

【英文标题】：StyleCop SA1124 DoNotUseRegions is reasonable? [closed]StyleCop SA1124 DoNotUseRegions 是否合理？ [关闭]

【发布时间】：2011-01-26 16:13:38

【问题描述】：

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

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

我想在检查代码样式时删除此规则。我可以知道您对此规则的看法吗？

【问题讨论】：

programmers.stackexchange.com/questions/53086/…

【参考方案1】：

在编写良好的代码中不再需要区域。隐藏机器生成的代码曾经很有用。现在该代码位于一个单独的文件中。区域仍然可以用来隐藏写得不好的代码。

【讨论】：

为了补充这个答案，我注意到要将机器生成的代码分隔到一个单独的文件中，可以使用 partial 类。

+1 似乎每次我在阅读别人的代码时遇到区域时，我认为如果他们将 OCD 倾向引导到更具架构生产力的东西上会更好，例如提取类等等。我就是这么做的！

【参考方案2】：

这将是个人喜好的事情。这里唯一重要的是您和您的团队喜欢什么。忘记 StyleCop 所说的吧，你是阅读它的人，你是维护它的人，无论有没有区域对你来说效果更好，这才是最重要的。

如果您将其作为开源项目发布...这是我的观点，我认为同样适用。使用核心团队更喜欢的任何东西。如果您有更多的团队成员加入并做出更多贡献，请稍后重新访问该问题，这总是可以更改的。

【讨论】：

这不是倒退吗？他们是编写它的人，尚未透露姓名的人必须阅读它。而地区肯定让这很尴尬。我个人的偏好是在我必须阅读代码时讨厌它们。

@nobugz - 目前，他们每天都在处理它，回去进行错误修复等......我仍然会说他们比其他任何人都阅读它。总的来说，无论如何我认为这是一个小问题，因为如果需要，您可以立即使用快速正则表达式将所有区域串起来。这和 Ctrl+M+L 使我可以很容易地使用或忽略它们，但可能是个人喜好。

或者在编辑器上。我将把我之前的评论改写为“影响成品”。

我同意是否使用区域是团队内部的协议。 Microsoft CAB 项目使用它，但 Microsoft Enterprise Library 5 不使用它。我认为大多数现有的 C# 项目都在使用区域，因为这听起来像是 C# 的一个很好的语法特性。使用它，避免被滥用是我的偏好。

StyleCop 规则可以更改，对吧？显然它们不是通用规则（此处为区域粉丝）

【参考方案3】：

我认为区域可能会被滥用，但它们是一种有用的技术，可以让读者一次专注于代码的某些区域。

不过，我会避免过多的嵌套。

【讨论】：

滥用区域会导致浏览代码不友好。在我的实践中，我不使用任何嵌套区域，只使用区域字段、属性、构造函数、接口实现、公共方法、私有和帮助方法。

【参考方案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完成，您可以转换您的区域划分为单独的类。

【参考方案5】：

根据我的经验，它们根本不应该被使用。初级开发人员倾向于滥用它们并创建过于复杂的类，其复杂性“巧妙地”隐藏在众多区域之后。

【参考方案6】：

在我看来，#region/#endregion 有一个例外： 实现接口时！

例如

#region Implementation of IDisposable
public void Dispose()

  // implementation here ...

#endregion

在所有其他情况下，您不应使用 #region，因为它们已过时（我假设为隐藏生成的代码而创建的位置 - .net-1.0 和 .net-1.1 但现在有部分类）

【参考方案7】：

我想知道这条规则是否是其他更普遍接受的规则的副作用，例如私有/受保护/公共成员的排序。在许多情况下，遵循这些排序规则必然会破坏 #regions 的逻辑分组，因此它们会变得互斥。