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