SA1124 DoNotUseRegions 建议不要在任何地方使用该区域。真的合理吗?
我认为区域是一种将相关代码组合在一起并使大类易于阅读的方法,例如,如果您通过上下文菜单为vs2008中的类生成接口方法,则会自动插入区域。
我想在检查代码样式时删除此规则。我可以知道你对这条规则的看法吗?
编写良好的代码不再需要区域。隐藏机器生成的代码曾经很有用。现在该代码位于一个单独的文件中。区域仍然可以用来隐藏写得不好的代码。
这将是个人喜好的事情。这里唯一重要的是您和您的团队喜欢什么。忘记 StyleCop 所说的,你是阅读它的人,你是维护它的人,无论有没有区域对你来说效果更好,这才是最重要的。
如果你将它作为一个开源项目发布......这是我的观点,我认为同样适用。使用核心团队更喜欢的任何东西。如果您有更多的团队成员加入并做出更多贡献,请稍后重新访问该问题,这总是可以更改的。
I like regions and my team and I feel code is more readable with them.
Here are the times when I love them...
If you have a company standard to write unit tests with Arrange Act Assert (AAA) then you could require unit tests to look as follows
[test]
public void MyFunction_Test
{
#region Arrange
#endregion
#region Act
#endregion
#region Assert
#endregion
}
I really like this format especially when there are clear separations and doing so inspires others to do something correctly, such as write unit tests correctly.
The other place I like region is code is when you know you are going to delete the code soon.
#region Drop this region next version when we drop 2003 support
public void DoSomeThingWithWindowsServer2003()
{
// code the is for Windows 2003 only
}
#endregion
I also use regions to separate the different parts of my classes even if the class is very small.
#region Constructors
#endregion
#region Properties
#endregion
#region Events
#endregion
#region Methods
#endregion
#region Enums
#endregion
Usually a class won't have all of these (if it does you may wonder if you are doing too much in a single class) but I think if you are looking for a single method or property, it is nice to have a single place to look. Not to mention a Property in a ViewModel (MVVM anybody?) using INotifyPropertyChanged is 10 lines (9 lines plus a space), so well-designed and well-written ViewModel object with only 5 properties, means the properties section is at least 50 lines of code.
I also especially like them when using someone else's poorly written code. It is silly to assume you can always refactor to use a perfect design. For example, you have a class with 2500 lines or more. Sure this probably could have been written better but you didn't do it, it works, and it is tested and your business has the code in "fix only" lockdown so refactoring isn't allowed. You can make an overly large class (poorly written or not) much more readable using #region statements. You get a lot of the readability benefits of separation of concerns without actually separating the class and then once the code comes out of lock down and you can refactor, the majority of the separation work may already be done using #regions and you can convert your regions into separate class.
我认为区域可能会被滥用,但它们是一种有用的技术,可以让读者一次专注于代码的某些区域。
但是,我会避免过多的嵌套级别。
根据我的经验,它们根本不应该被使用。初级开发人员倾向于滥用它们并创建过于复杂的类,其复杂性“巧妙地”隐藏在众多区域之后。
在我看来,#region/#endregion 有一个例外是有意义的:实现接口时!
例如
#region Implementation of IDisposable
public void Dispose()
{
// implementation here ...
}
#endregion
在所有其他情况下,您不应使用#region,因为它们已过时(我假设为隐藏生成的代码而创建的位置 - .net-1.0 和 .net-1.1 但现在有部分类)
我想知道这条规则是否是其他更普遍接受的规则的副作用,例如私有/受保护/公共成员的排序。在许多情况下,遵循这些排序规则必然会破坏#regions 的逻辑分组,因此它们会变得互斥。