您如何看待代码折叠？ [关闭]

Posted 2023-02-26

技术标签:

【中文标题】您如何看待代码折叠？ [关闭]【英文标题】：How do you feel about code folding? [closed] 【发布时间】：2010-09-05 13:49:39 【问题描述】：

对于那些在 Visual Studio 环境中的人，您对将任何代码包装在 #regions 中感觉如何？（或者如果任何其他 IDE 有类似的东西......）

【问题讨论】：

你必须知道什么时候拿着它们，知道什么时候折叠它们——肯尼·罗杰斯。 【参考方案1】：

我使用Textmate（仅限 Mac），它具有代码折叠功能，我发现它对折叠函数非常有用，我知道我的“getGet”函数做了什么，我不需要它占用 10 行哦，太有价值了屏幕空间。

我从不使用它来隐藏 for 循环、if 语句或类似语句，除非将代码显示给其他人，在那里我将隐藏他们看到的代码以避免重复显示相同的代码。

【讨论】：

【参考方案2】：

这是在Coding Horror上讨论的。

我个人认为它们是有用的，但就像任何过度的东西都可能太多了。

我用它来将我的代码块排序到：枚举声明构造函数方法事件处理程序属性

【讨论】：

如果您有 1 个属性，您仍将其包装在区域块中吗？ :( 如果类文件更容易导航的话。通常，如果它的课程很短，但地区不会有帮助，所以我省略了它们。不是一篇很有见地的文章。【参考方案3】：

我个人一直使用#Regions。我发现这有助于我将属性、声明等内容彼此分开。

这可能也是一个很好的答案！

Coding Horror

编辑：Dang，Pat 打败了我！

【讨论】：

【参考方案4】：

虽然我理解 Jeff 等人的问题。人。有区域，我不明白为什么要点击 CTRL+M,CTRL+ L 扩展一个文件中的所有区域太难处理了。

【讨论】：

【参考方案5】：

我自己更喜欢#regions，但一位老同事无法忍受隐藏东西。一旦我在一个有 7 个#regions 的页面上工作，我就理解了他的观点，其中至少有 3 个是自动生成的并且具有相同的名称，但总的来说，我认为它们是一种有用的方式来拆分事物并减少所有内容杂乱无章。

【讨论】：

【参考方案6】：

我更喜欢局部类而不是区域。

其他人对区域的广泛使用也给我一种印象，即某人在某处违反了单一职责原则，并试图用一个对象做太多事情。

【讨论】：

【参考方案7】：

我不喜欢部分课程 - 我尝试开发我的课程，以便每个课程都有一个非常清晰、单一的问题，由它负责。为此，我不认为应该将具有明确责任的内容拆分到多个文件中。这就是我不喜欢偏类的原因。

话虽如此，我对地区持观望态度。大多数情况下，我不使用它们。然而，我每天都在处理包含区域的代码——有些人对它们非常重视（将私有方法折叠到一个区域中，然后每个方法都折叠到它自己的区域中），有些人对它们很轻（折叠枚举，折叠属性等）。到目前为止，我的一般经验法则是，我只在以下情况下将代码放在区域中：（a）数据可能保持静态或不会经常被触及（如枚举），或者（b）如果有方法由于子类化或抽象方法的实现，它们是出于必要而实现的，但同样不会经常被触及。

【讨论】：

【参考方案8】：

有时您可能会发现自己在一个鼓励或要求使用 #regions 的团队工作。如果您像我一样无法忍受折腾代码，您可以关闭 C# 的大纲：

选项 -> 文本编辑器 -> C# -> 高级选项卡取消选中“打开文件时进入大纲模式”

【讨论】：

【参考方案9】：

我用#Region来隐藏丑陋无用的自动生成代码，真正属于partial类的自动生成部分。但是，在处理旧项目或升级项目时，您并不总是拥有这种奢侈。

至于其他类型的折叠，我一直折叠函数。如果你给函数命名得当，除非你正在测试或（重新）编写它，否则你永远不必往里面看。

【讨论】：

【参考方案10】：

@Tom

提供了部分类，以便您可以将工具自动生成的代码与代码生成完成后可能需要进行的任何自定义分开。这意味着您的代码在您重新运行 codegen 后保持不变并且不会被覆盖。这是一件好事。

【讨论】：

【参考方案11】：

使用#region 来组织代码我真的没有问题。就个人而言，我通常会为属性、事件处理程序和公共/私有方法等设置不同的区域。

【讨论】：

【参考方案12】：

Eclipse 自己在 Java（或带有插件的 php）中完成了其中的一些工作。允许您折叠功能等。我倾向于喜欢它。如果我知道一个函数是做什么的，但我没有处理它，我就不需要看它。

【讨论】：

【参考方案13】：

10 次中有 9 次代码折叠意味着您未能充分利用 SoC principle 的价值。我或多或少对部分课程有同样的感觉。如果您认为有一段代码太大，则需要将其分成可管理（和可重用）的部分，而不是隐藏或拆分它。下次有人需要更改它时，它会咬你，并且看不到方法的 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 美元。

【讨论】：

我认为部分类主要是为了提供一种向生成的代码添加功能的安全方式？确实如此。如果您设计一个类的方式迫使您将其拆分为多个文件以提高可读性，那么您就失败了。我不这么认为，Java 不支持像 dotNet 这样的部分类，然后想想你需要用复杂的 GUI 做什么。 LongTTH：你不想要部分类，你想要多个类的组合。【参考方案14】：

绝不能在方法内部使用区域。它们可以用于对方法进行分组，但必须非常小心地处理，以免代码的读者发疯。通过它们的修饰符折叠方法是没有意义的。但有时折叠可能会增加可读性。例如将您在使用外部库时用于解决某些问题并且您不想经常访问的一些方法进行分组可能会有所帮助。但是编码人员必须始终寻求解决方案，例如在这个特定示例中使用适当的类包装库。当所有其他方法都失败时，使用折叠来提高可读性。

【讨论】：

【参考方案15】：

如果使用得当，我认为它是一个有用的工具。在很多情况下，我觉得方法和枚举等经常被折叠的东西应该是小黑箱。除非您出于某种原因必须查看它们，否则它们的内容无关紧要，应尽可能隐藏。但是，我从不折叠私有方法、cmets 或内部类。方法和枚举真的是我唯一折叠的东西。

【讨论】：

【参考方案16】：

我的方法与这里的其他一些方法类似，使用区域将代码块组织成构造函数、属性、事件等。

Roland Weigelt 的博客文章Better Keyboard Support for #region ... #endregion 提供了一组出色的 VS.NET 宏。我多年来一直在使用这些，映射 ctrl+。折叠当前区域并 ctrl++ 展开它。发现折叠/展开所有内容的默认 VS.NET 功能效果要好得多。

【讨论】：

【参考方案17】：

Coding Horror 的文章实际上也让我想到了这一点。

通常，对于大型类，我会在成员变量、常量和属性周围放置一个区域，以减少我必须滚动浏览的文本量，并将其他所有内容留在区域之外。在表单上，我通常将事物分组为“成员变量、常量和属性”、表单函数和事件处理程序。再一次，这更重要的是，当我只想查看一些事件处理程序时，我不必滚动浏览大量文本。

【讨论】：

【参考方案18】：

Emacs 有一个折叠次要模式，但我只是偶尔启动它。大多数情况下，当我正在研究从另一个物理学家那里继承来的怪物时，他显然没有多少指导或不太关心他/她的编码实践。

【讨论】：

【参考方案19】：

这只是那些毫无结果的愚蠢讨论之一。如果您喜欢区域，请使用它们。如果您不这样做，请将您的编辑器配置为关闭它们。在那里，每个人都很开心。

【讨论】：

我不同意。没有任何讨论能让人们思考他们为什么要做某事（可能是为什么他们一直在做某事），并评估未来更好的工作方式，这是毫无结果的。【参考方案20】：

使用区域（或以其他方式折叠代码）应该与代码异味（或隐藏它们）或您不希望人们“轻易”看到的任何其他隐藏代码的想法无关。

区域和代码折叠实际上就是提供一种方法来轻松地对可以折叠/折叠/隐藏的代码部分进行分组，以最大限度地减少围绕您当前工作的无关“噪音”的数量。如果您设置正确（意味着实际上将您的区域命名为有用的名称，例如包含的方法的名称），那么您可以折叠除当前正在编辑的函数之外的所有内容，并且仍然保持一定程度的上下文，而无需实际查看其他内容代码行。

可能应该有一些围绕这些想法的最佳实践类型指南，但我广泛使用区域来为我的代码文件提供标准结构（我对事件、类范围的字段、私有属性/方法、公共属性/方法进行分组） .每个方法或属性也有一个区域，其中区域名称是方法/属性名称。如果我有一堆重载方法，则区域名称是完整的签名，然后整个组被包装在一个仅是函数名称的区域中。

【讨论】：

【参考方案21】：

如果我不必根据我的代码固有的语言特性手动维护区域分组，那么区域折叠会很好。例如，编译器已经知道它是一个构造函数。 IDE 的代码模型已经知道它是一个构造函数。但是，如果我想查看构造函数组合在一起的代码视图，出于某种原因，我必须重申这些东西是构造函数的事实，方法是将它们物理地放在一起，然后在它们周围放置一个组。任何其他分割类/结构/接口的方式也是如此。如果我改变主意并希望看到先将公共/受保护/私有内容分成组，然后按成员种类分组怎么办？

使用区域来标记公共属性（例如）与输入多余的注释一样糟糕，这对从代码本身已经可辨别的内容没有任何添加。

无论如何，为了避免为此目的使用区域，我编写了一个免费的开源 Visual Studio 2008 IDE 插件，名为 Ora。它自动提供了一个分组视图，大大减少了维护物理分组或使用区域的必要性。 You may find it useful.

【讨论】：

【参考方案22】：

我通常发现，在处理像 C# 中的事件之类的代码时，大约有 10 行代码实际上只是事件声明的一部分（EventArgs 类、委托声明和事件声明）在它们周围放置一个区域，然后将它们折叠起来使其更具可读性。

【讨论】：

【参考方案23】：

我个人讨厌地区。在我看来，唯一应该在区域中的代码是生成的代码。当我打开文件时，我总是从 Ctrl+M+O 开始。这折叠到方法级别。当您有区域时，您只会看到区域名称。

在签入之前，我对方法/字段进行了逻辑分组，以便在 Ctrl+M+O 之后看起来没问题。如果你需要区域，你的班级必须有很多行。我也发现这很常见。