C# StyleCop SA1124 DonotUserRegions是否合理？_C#_Stylecop

C# StyleCop SA1124 DonotUserRegions是否合理？

C# StyleCop SA1124 DonotUserRegions是否合理？,c#,stylecop,C#,Stylecop,SA1124 DonotUserRegions建议不要在任何地方使用该区域。这真的合理吗我认为region是一种将相关代码组合在一起并使大型类易于阅读的方法，例如，如果您通过上下文菜单为vs2008中的类生成接口方法，则会自动插入一个region 我想在检查代码样式时删除此规则。我可以知道你对这条规则的看法吗？这将是个人偏好。这里唯一重要的是你和你的团队喜欢什么。忘记StyleCop说的吧，你是阅读它的人，你是维护它的人，不管有没有区域对你来说都更好，这才是最重要的如果你把它作为一个开源项目

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

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

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

这将是个人偏好。这里唯一重要的是你和你的团队喜欢什么。忘记StyleCop说的吧，你是阅读它的人，你是维护它的人，不管有没有区域对你来说都更好，这才是最重要的

如果你把它作为一个开源项目发布……这是我的观点，我认为同样适用。使用核心团队更喜欢的任何东西。如果您有更多的团队成员加入，并且做出了更多贡献，请稍后再次访问该问题，这总是可以改变的。

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

但是，我会避免太多层次的嵌套。

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

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

在我看来，有一个例外其中#区域/#结束区域有意义：在实现接口时

e、 g

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

--Harald RenéFlasch（又名hfrmobile）

我喜欢地区和我的团队，我觉得代码更容易阅读

这是我爱他们的时刻

如果您有使用ArrangeActAssert（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 Anywhere？）中的属性是10行（9行加一个空格），因此设计良好且编写良好的ViewModel对象只有5个属性，这意味着属性部分至少有50行代码

当我使用别人写得很差的代码时，我也特别喜欢它们。假设您总是可以通过重构来使用完美的设计是愚蠢的。例如，您有一个包含2500行或更多行的类。当然，这本可以写得更好，但你没有做到，它是有效的，并且经过测试，你的公司的代码处于“仅修复”锁定状态，因此不允许重构。您可以使用#region语句使一个过大的类（写得不好或写得不好）更具可读性。在不分离类的情况下分离关注点可以带来很多可读性好处，一旦代码解除锁定，您就可以进行重构，大部分分离工作可能已经使用#区域完成，您可以将区域转换为单独的类。

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

这不是在倒退吗？是他们写的，到目前为止还没有名字的人不得不读。而这些地区确实让人尴尬。我个人的偏好是，当我必须阅读代码时，我会讨厌他们。@nobugz-目前，他们每天都在处理代码，回去修复错误等等。我仍然认为他们阅读代码的次数比任何人都多。总之，我认为这是个小问题，因为如果需要的话，你可以在任何时候用快速正则表达式串出所有区域。这和Ctrl+M+L使我可以很容易地使用或忽略它们，但可能是个人偏好。或者在编辑器上。我将把我之前的评论改为“影响成品”。我同意使用或不使用区域是团队内部的协议。Microsoft CAB project使用它，但Microsoft Enterprise Library 5不使用它。我认为大多数现存的C#项目都使用region，因为它听起来像是C#的一个很好的语法特性。使用它，避免被滥用是我的首选。StyleCop规则可以更改，对吗？显然，它们并不是通用规则（这里是regions fan），在使用region时被滥用会使浏览代码变得不友好。在我的实践中，我不使用任何嵌套区域，只使用区域字段、属性、构造函数、接口实现、公共方法、私有方法和帮助方法，人们会使用

partial

类。+1似乎每次我在阅读其他人的代码时遇到区域，我认为如果他们转而将他们的OCD倾向引导到架构上更高效的东西，比如Extract类等等，会更好。我就是这么做的！

#region Constructors
#endregion

#region Properties
#endregion

#region Events
#endregion

#region Methods
#endregion

#region Enums
#endregion