How do you feel about code folding?对于在Visual Studio环境中的那些人，您对将任何代码包装在#region中的感觉如何？ (或者其他任何IDE具有类似的功能...)
十分之九的代码折叠意味着您未能充分利用SoC原理的价值。 只要有可能，就从主类中提取一些代码，并放入帮助程序或工厂类中。
不如
反正我的$ 0.02。 在编码恐怖中讨论过这一点。 我个人认为这是有用的，但就像任何多余的东西一样，它们可能太多了。
我用它来将代码块排序为： 有时，您可能会发现自己在一个鼓励或要求#region的团队中工作。如果您像我一样，又受不了折叠的代码，可以关闭C＃的概述： 我使用#Region隐藏丑陋且无用的自动生成的代码，这些代码实际上属于分部类的自动生成部分。但是，在处理旧项目或升级项目时，您并不总是那么奢侈。 至于其他类型的折叠，我一直都在折叠功能。如果您对该函数命名正确，则除非您正在测试或重新编写它，否则您将无需查看内部。 虽然我了解Jeff等人的问题。等对于区域，我不明白的是为什么很难按CTRL + M，CTRL + L来扩展文件中的所有区域。 汤姆 提供了部分类，以便您可以将工具自动生成的代码与代码生成完成后可能需要进行的任何自定义分离。这意味着在您重新运行代码生成后，您的代码将保持不变，并且不会被覆盖。这是一件好事。 我更喜欢局部类而不是区域。 其他人对区域的广泛使用也给我一种印象，即某处某人违反了"单一责任原则"，并试图用一个对象做太多事情。 我使用具有代码折叠功能的Textmate(仅限Mac)，并且发现它对于折叠功能确实非常有用，我知道我的" getGet"功能可以做什么，我不需要占用10行如此宝贵的屏幕空间。 我从不使用它来隐藏for循环，if语句或类似语句，除非向他人显示代码，否则我将隐藏他们看到的代码，以避免两次显示相同的代码。 我通常会发现，在处理诸如C＃中的事件之类的代码时，大约有10行代码实际上只是事件声明的一部分(EventArgs类，委托声明和事件声明)，在它们周围放置一个区域，然后将它们折叠起来这种方式使它更具可读性。 如果我不必根据语言固有的代码功能手动维护区域分组，则区域折叠会很好。例如，编译器已经知道它是构造函数。 IDE的代码模型已经知道它是构造函数。但是，如果我想查看将构造函数组合在一起的代码视图，出于某种原因，我必须通过物理地将它们放在一起然后在它们周围放一个组来重申这些东西是构造函数这一事实。切片类/结构/接口的任何其他方式也是如此。如果我改变主意并希望看到公共/受保护/私有内容首先分成几组，然后再按成员类别分组怎么办？ 例如，使用区域标记公共属性就像输入一个多余的注释一样，该注释不会为代码本身已经可以识别的内容添加任何内容。 无论如何，为了避免为此目的而使用区域，我编写了一个免费的开源Visual Studio 2008 IDE加载项Ora。它会自动提供分组视图，因此无需再进行物理分组或使用区域。您可能会发现它很有用。 这只是无聊的无聊讨论之一。如果您喜欢区域，请使用它们。如果没有，请配置您的编辑器以将其关闭。在那里，每个人都很高兴。 禁止在方法内部使用区域。它们可能用于对方法进行分组，但是必须格外谨慎地进行处理，以使代码阅读者不会疯狂。折叠方法的修饰符没有意义。但是有时折叠可以提高可读性。例如对使用外部库时不希望经常访问的一些方法进行分组可能会有所帮助。但是，在此特定示例中，编码人员必须始终寻求解决方案，例如用适当的类包装库。当所有其他方法均失败时，请使用折叠功能以提高可读性。 我不喜欢局部类-我尝试开发自己的类，以使每个类都有一个非常明确的单一问题来负责。为此，我不认为应该将职责明确的内容拆分到多个文件中。这就是为什么我不喜欢局部类的原因。 话虽这么说，我对地区的束缚。在大多数情况下，我不使用它们。但是，我每天都在处理包含区域的代码-有些人对它们非常重视(将私有方法折叠到一个区域中，然后将每种方法折叠到自己的区域中)，而有些人则对它们轻描淡写(折叠枚举，折叠属性等)。到目前为止，我的一般经验法则是，我仅在以下情况下将代码放在区域中：(a)数据很可能保持静态或不会经常被访问(例如枚举)，或者(b)如果存在某些方法可以由于子类化或抽象方法的实现而不必要地实现，但是同样，也不会经常被使用。 我的方法与此处的其他方法类似，使用区域将代码块组织到构造函数，属性，事件等中。 Roland Weigelt在他的博客文章"对#region ... #endregion的更好的键盘支持"中提供了一组出色的VS.NET宏。我已经使用这些工具多年了，映射ctrl +。折叠当前区域，然后按ctrl ++进行扩展。发现它比折叠/展开所有内容的默认VS.NET功能要好得多。 我认为，如果使用得当，它是一个有用的工具。在许多情况下，我认为方法和枚举以及其他经常折叠的东西应该是小的黑匣子。除非出于某种原因必须查看它们，否则它们的内容无关紧要，应尽可能隐藏。但是，我从未折叠私有方法，注释或内部类。方法和枚举实际上是我唯一要折叠的东西。 我一直都在使用#Regions。我发现这有助于我将诸如属性，声明等彼此分开。 这也可能是一个很好的答案！ 编码恐怖 编辑：ang，帕特击败了我！ 我本人更喜欢#regions，但是一个老同事无法忍受隐藏事物。一旦我在包含7个#region的页面上工作，我就理解了他的观点，其中至少3个是自动生成的，并且具有相同的名称，但是总的来说，我认为它们是将内容分解并减少所有内容的有用方法杂乱无章。 Eclipse自己用Java(或带插件的PHP)完成了其中的一些工作。允许您折叠功能等。我倾向于喜欢它。如果我知道某个函数的功能而我没有在使用它，则无需查看它。 枚举 性质 .ctors 方法 事件处理程序 这就是我使用区域的全部。我不知道您可以在方法内部使用它们。 听起来像个可怕的主意:) 实际上，《 Coding Horror》一文也让我思考了一下。 通常，在大型类中，我会在成员变量，常量和属性周围放置一个区域，以减少需要滚动浏览的文本量，并将其他所有内容都保留在区域之外。在表单上，??我通常将事物分为"成员变量，常量和属性"，表单函数和事件处理程序。再说一遍，这是更多的事情，所以当我只想回顾一些事件处理程序时，我不必滚动很多文本。 Emacs具有可折叠的次要模式，但我只是偶尔启动它。通常，当我在研究从另一位物理学家那里继承来的怪兽时，显然他的指导较少或对他/她的编码实践不太关心。 使用区域(或以其他方式折叠代码)应该与代码气味(或隐藏它们)或任何其他您不希望人们"轻松"看到的隐藏代码想法无关。 区域和代码折叠实际上就是提供一种轻松地对可以折叠/折叠/隐藏的代码段进行分组的方法，以最大程度地减少当前正在处理的代码中多余的"噪音"。如果正确设置(意味着实际上给您的区域命名了一些有用的东西，例如所包含的方法的名称)，那么您可以折叠除当前正在编辑的功能以外的所有内容，并且仍然保持一定程度的上下文，而无需实际查看其他内容代码行。 围绕这些想法可能应该有一些最佳实践类型指南，但是我广泛使用区域来为我的代码文件提供标准结构(我对事件，全类字段，私有属性/方法，公共属性/方法进行分组)。每个方法或属性还具有一个区域，其中区域名称是方法/属性名称。如果我有一堆重载的方法，则区域名称是完整的签名，然后将整个组包装在仅是函数名称的区域中。
我个人讨厌地区。我认为应该在区域中的唯一代码是生成的代码。
在对I / I进行逻辑分组之前，请按逻辑对方法/字段进行分组，以便在Ctrl + M + O之后看起来可以。 地区ThisLooksLikeWellOrganizedCode因为IUseRegions //总垃圾，这里没有结构 末端区域 使用#region来组织代码确实没有问题。就个人而言，我通常会为属性，事件处理程序和公共/私有方法等设置不同的区域。 |
