使用“region”作为快速修复,以避免重构成更小的函数

以前 partial Visual Studio使用它来分离自动生成的代码和用户定义的代码。

这是一个维护项目,它可能帮助开发人员跟踪他们的类,也可能不帮助开发人员跟踪他们的类,还可能避免相互干涉代码。对于那些没有发现它们有用的人,不要使用它们。对于我们的团队,我们定义了一个使用它们的标准,我们基本上都遵循这个标准。把东西扔到某个区域会使问题变得更糟,所以采用一个标准并坚持下去(无论你选择哪种方式)总是好的。

使代码模糊

它的懒惰编码。 如果方法中有区域。它应该被重构成更小的方法。

使代码更可读,更易于浏览。它不仅仅是为函数设计的,它在类范围内更有用。例如,您可能希望将不同类型的方法、字段、属性等组合在一起。

当您在函数中使用区域时,您可能应该考虑重构

#region Getters and setters
...
#endregion

在我创建的每个类中。这些几乎永远不会改变,我也不需要在课堂上工作的时候把我的观点弄得乱七八糟。

有很多情况——通常在类范围内,但有时在函数范围内,语言的规则需要生成大量重复代码。region的一个很好的用途是用一行指示被替换内容的代码替换大量这样的代码。例如,在VB中,如果希望有许多只读属性由私有读写字段支持,则可以声明这些字段,然后有一个“region”,其描述为“foo、bar、baz和fnord的简单只读属性”。这些属性的代码为20行(加上每个属性之间通常有一个空行),但是任何读过描述的人都会确切地知道那20行要说什么。给出十几个程序员的描述,以及变量的声明,所有这些程序员都可能为字符相同的代码生成字符(可能的情况下,除了属性间的间隔和注释)。为什么要把编辑弄得一团糟?

我也不喜欢用它,但我在一个特别的情况下用过它。我有一个本地域创建工具,用来创建/设置我们托管的初始客户站点。创建过程中大约有20个部分,所以我使用了区域块来划分这些部分…唯一的目的是组织…但我之前无意中删除了整个代码块,因为折叠的区域标记与其他代码一起被选中…我不建议养成使用它们的习惯。

我使用 #region 指令。我在每个文件中都有常量、字段、属性、构造函数、重写等节(尽管不是每次都有)。这是我自己的个人编码标准,它可以帮助我快速找到东西。我从来没有 #地区 #地区