对于那些在 Visual Studio 环境中的人,您对将任何代码包装在#regions 中感觉如何?(或者如果任何其他 IDE 有类似的东西......)
24 回答
十次中有九次,代码折叠意味着你没有使用SoC 原理来实现它的价值。
我或多或少对部分课程有同样的感觉。如果你有一段你认为太大的代码,你需要把它分成可管理(和可重用)的部分,而不是隐藏或拆分它。
下次有人要改的时候它会咬你,而且看不到一个250行怪物的方法中隐藏的逻辑。
只要有可能,就将一些代码从主类中拉出,并放入助手类或工厂类中。
foreach (var item in Items)
{
//.. 100 lines of validation and data logic..
}
可读性不如
foreach (var item in Items)
{
if (ValidatorClass.Validate(item))
RepositoryClass.Update(item);
}
反正我的 0.02 美元。
有时,您可能会发现自己在一个鼓励或需要#regions 的团队中工作。如果您像我一样无法忍受折腾代码,您可以关闭 C# 的大纲:
- 选项 -> 文本编辑器 -> C# -> 高级选项卡
- 取消选中“打开文件时进入大纲模式”
虽然我理解杰夫等人的问题。人。有区域,我不明白为什么点击CTRL+ M,CTRL+L来扩展文件中的所有区域是如此难以处理。
我用#Region来隐藏丑陋无用的自动生成代码,真正属于partial类的自动生成部分。但是,在处理旧项目或升级项目时,您并不总是那么奢侈。
至于其他类型的折叠,我一直折叠函数。如果你很好地命名函数,除非你正在测试或(重新)编写它,否则你将永远不必查看内部。
我使用具有代码折叠功能的Textmate(仅限 Mac),我发现它对折叠功能非常有用,我知道我的“getGet”功能是做什么的,我不需要它占用 10 行非常宝贵的屏幕空间。
我从不使用它来隐藏 for 循环、if 语句或类似语句,除非将代码显示给其他人,我将隐藏他们看到的代码以避免重复显示相同的代码。
我更喜欢部分类而不是区域。
其他人对区域的广泛使用也给我一种印象,即某人在某处违反了单一职责原则,并试图用一个对象做太多事情。
@汤姆
提供了部分类,以便您可以将工具自动生成的代码与代码生成完成后可能需要进行的任何自定义分开。这意味着您的代码在您重新运行 codegen 后保持不变并且不会被覆盖。这是一件好事。
我不喜欢部分课程 - 我尝试开发我的课程,以便每个课程都有一个非常清晰、单一的问题,由它负责。为此,我不认为应该将具有明确责任的内容拆分到多个文件中。这就是为什么我不喜欢部分课程。
话虽如此,我对地区持观望态度。大多数情况下,我不使用它们。然而,我每天都在处理包含区域的代码——有些人对它们非常重视(将私有方法折叠到一个区域中,然后每个方法都折叠到它自己的区域中),有些人对它们很轻(折叠枚举,折叠属性等)。到目前为止,我的一般经验法则是,我只在以下情况下将代码放在区域中:(a)数据可能保持静态或不会经常被触及(如枚举),或者(b)如果有方法由于子类化或抽象方法的实现,它们是出于必要而实现的,但同样不会经常被触及。
绝不能在方法内部使用区域。它们可以用于对方法进行分组,但必须非常小心地处理,以免代码的读者发疯。通过它们的修饰符折叠方法是没有意义的。但有时折叠可能会增加可读性。例如,在使用外部库时将一些用于解决某些问题的方法进行分组,并且您不想经常访问可能会有所帮助。但是编码人员必须始终寻求解决方案,例如在这个特定示例中使用适当的类包装库。当一切都失败时,使用折叠来提高可读性。
这只是那些毫无结果的愚蠢讨论之一。如果您喜欢区域,请使用它们。如果您不这样做,请将您的编辑器配置为关闭它们。在那里,每个人都很高兴。
如果我不必根据我的代码固有的语言特性手动维护区域分组,那么区域折叠会很好。例如,编译器已经知道它是一个构造函数。IDE 的代码模型已经知道它是一个构造函数。但是,如果我想查看构造函数组合在一起的代码视图,出于某种原因,我必须重申这些东西是构造函数的事实,将它们物理地放在一起,然后在它们周围放置一个组。任何其他分割类/结构/接口的方式也是如此。如果我改变主意并希望看到公共/受保护/私人的东西首先分成组,然后按成员类型分组怎么办?
使用区域来标记公共属性(例如)与输入冗余注释一样糟糕,该注释不会对已经从代码本身可辨别的内容添加任何内容。
无论如何,为了避免为此目的使用区域,我编写了一个免费的开源 Visual Studio 2008 IDE 插件,名为 Ora。它自动提供了一个分组视图,大大减少了维护物理分组或使用区域的必要性。您可能会发现它很有用。
我通常发现,在处理诸如 C# 中的事件之类的代码时,大约有 10 行代码实际上只是事件声明的一部分(EventArgs 类、委托声明和事件声明)在它们周围放置一个区域,然后将它们折叠起来的方式使它更具可读性。
我认为如果使用得当,它是一个有用的工具。在很多情况下,我觉得方法和枚举等经常被折叠的东西应该是小黑箱。除非您出于某种原因必须查看它们,否则它们的内容无关紧要,应尽可能隐藏。但是,我从不折叠私有方法、注释或内部类。方法和枚举真的是我唯一折叠的东西。
我的方法与这里的其他一些方法类似,使用区域将代码块组织成构造函数、属性、事件等。
Roland Weigelt 的博客文章“#region ... #endregion 更好的键盘支持”中提供了一组出色的 VS.NET 宏。我多年来一直在使用这些,映射 ctrl+。折叠当前区域并 ctrl++ 展开它。发现折叠/展开所有内容的默认 VS.NET 功能效果要好得多。
我自己更喜欢#regions,但一位老同事无法忍受隐藏东西。一旦我在一个有 7 个#regions 的页面上工作,我就理解了他的观点,其中至少有 3 个是自动生成的并且具有相同的名称,但总的来说,我认为它们是一种有用的方式来拆分事物并减少所有内容杂乱无章。
我真的没有使用#region 来组织代码的问题。就个人而言,我通常会为属性、事件处理程序和公共/私有方法等设置不同的区域。
Eclipse 自己在 Java(或带有插件的 PHP)中完成了其中的一些工作。允许您折叠功能等。我倾向于喜欢它。如果我知道一个函数的作用并且我没有在处理它,我就不需要看它。
Coding Horror文章实际上也让我想到了这一点。
通常,对于大型类,我会在成员变量、常量和属性周围放置一个区域,以减少我必须滚动浏览的文本量,并将其他所有内容留在区域之外。在表单上,我通常会将事物分组为“成员变量、常量和属性”、表单函数和事件处理程序。再一次,这更重要的是,当我只想查看一些事件处理程序时,我不必滚动浏览大量文本。
Emacs 有一个折叠次要模式,但我只是偶尔启动它。大多数情况下,当我正在研究从另一个物理学家那里继承来的怪物时,他显然没有多少指导或不太关心他/她的编码实践。
使用区域(或以其他方式折叠代码)应该与代码气味(或隐藏它们)或任何其他隐藏代码的想法无关,您不希望人们“轻易”看到。
区域和代码折叠实际上就是提供一种方法来轻松地对可以折叠/折叠/隐藏的代码部分进行分组,以最大限度地减少您当前正在处理的外部“噪音”的数量。如果您设置正确(意味着实际上将您的区域命名为有用的名称,例如包含的方法的名称),那么您可以折叠除当前正在编辑的函数之外的所有内容,并且仍然保持一定程度的上下文,而无需实际查看其他内容代码行。
围绕这些想法可能应该有一些最佳实践类型指南,但我广泛使用区域来为我的代码文件提供标准结构(我对事件、类范围的字段、私有属性/方法、公共属性/方法进行分组)。每个方法或属性也有一个区域,其中区域名称是方法/属性名称。如果我有一堆重载方法,则区域名称是完整的签名,然后整个组被包装在一个只是函数名称的区域中。
我个人讨厌地区。在我看来,唯一应该在区域中的代码是生成的代码。当我打开文件时,我总是从 Ctrl+M+O 开始。这折叠到方法级别。当您有区域时,您只会看到区域名称。
在签入之前,我对方法/字段进行了逻辑分组,以便在 Ctrl+M+O 之后看起来没问题。如果你需要区域,你的班级必须有很多行。我也发现这很常见。
区域 ThisLooksLikeWellOrganizedCodeBecauseIUseRegions
// 总垃圾,这里没有结构
端区
枚举
特性
.ctors
方法
事件处理程序
这就是我使用区域的全部内容。我不知道你可以在方法中使用它们。
听起来是个糟糕的主意:)