格式化代码的正确方法是什么？答案

【问题标题】：What is the proper way to format code?格式化代码的正确方法是什么？
【发布时间】：2011-09-15 22:37:40
【问题描述】：

当我写代码时，我会尝试将相似的代码行组合在一起，然后留下一个空行并编写另一个代码块。

我相信这有助于代码的简洁性和可读性。

我不喜欢在没有任何行距的情况下将东西捆绑在一起。它看起来像地狱，很难阅读，也很难理解。

我的一位老师降级了我的一项作业，因为我在逻辑上分隔了我的代码。他说，“当你必须在现实世界中整天阅读代码时，你不会输入这个行距，你会感谢我的。”当然，我从来没有也永远不会感谢他。

现在我在现实世界中，我看到的大多数绝对没有行距的代码文件都是写得不好，考虑得不好。

这在 VB 类型语言中可能比在 C 类型语言中更普遍，但同样的概念也适用。

想到两个问题：

您在代码中的什么地方留空行？
多少行距才算太大？

【问题讨论】：

“他是个混蛋（他为什么要教书）”？？ wtf?
呵呵。错字，但我要离开它，只是因为。你知道这句话，'那些不能教书的人'。亚达亚达亚达
".. 并且考虑不周".. 这实际上是一个好点 - 划分为逻辑分组意味着您正在单独考虑代码的每个部分，而不是作为一些庞然大物的方法
已编辑：删除了关于该教师的完全不相关的评论。提问时请坚持事实。
这不应该是社区维基吗？

标签： formatting

【解决方案1】：

我关注Microsoft's Guidelines for C#。

编辑：standard for C# 是不要与 IDE 对抗。如果您点击CTRL K+D，IDE 将自动在代码段之间放置空行。

接下来，如果您查看 MSDN 或 anywhere else 上的 C# 示例代码，通常每个逻辑放置的组之间都有一个空行。所以你所有的成员变量后面都会有一个空行，每个方法后面都有一个空行，等等。

为了回应 cmets 对我使用 IDE 进行 C# 编程表示震惊和恐惧：

真正的程序员

【讨论】：

另外，如果你按照你所看到的，你将需要使用他们古怪的 HTML 缩进规则......
任何定义可以和不能放置空格的规范对我来说都是一个很大的负面影响（除了标记一致性是关键的 API 文档）。空格或缺少空格不会增加或降低代码的可理解性。准则应该是关于代码的可理解性。
@Skizz，失败！当然，如果您的可读性较低，它确实会降低可用性。
我认为 Ctrl+K+D 不会在方法中的逻辑代码块之间添加间距，这就是问题所在。
@Peter Lillevold：作者不清楚。所以我必须解释。我的回答是 IDE 告诉我们应该在哪里放置空行，在它说不应该放置的地方，我们不应该。

【解决方案2】：

我想我会做类似的事情，但没有硬性规定。我喜欢将代码分隔在分组/相关逻辑的“段落”中。

没有额外行空间的代码读起来很糟糕。

【讨论】：

【解决方案3】：

听起来我的代码行与您相似。

但这是无关紧要的个人偏好，每个人都会有自己的“正确方式”来做这件事。恕我直言，最重要的是适应您要进入的环境风格。

此外，您会在“现实世界”中找到这样的代码……但听起来您有更高的抱负。 ;-)

编辑：......不是比“现实世界”更高的抱负，而是高于“现实世界”中常见的平庸废话。 ...但是，如果您碰巧有比“现实世界”更高的抱负，您可能希望看到专业人士。 ;-)

【讨论】：

【解决方案4】：

我的经验法则是：

在块之间放置一个空行可以用一个来描述的代码评论。

但总的来说，我同意许多具有大量空白的大型函数应该分解为更小的函数。

【讨论】：

【解决方案5】：

由于我们没有您个人关于“逻辑”行距的想法的示例，因此我们无法确定您是否应该被降级。

我倾向于在间隔之前将序列中相似的语句或步骤组合在一起（例如变量声明、循环等）

【讨论】：

【解决方案6】：

基本上和其他人说的一样。 COBOL 对什么是句子和段落有非常明确的规则。我想，在我的脑海里，我遵循那些。如果你有一个大的 IF 语句，你没有在嵌套的最后放置一个句点。同样，我在最后一个 } // end if 之后放了一个空行

是的，我把 // end if, // end for, // end 方法的东西放在那里。我认识的一些更直言不讳的人不喜欢它，但我喜欢它。他们说你不应该让你的 if 语句变得很大，如果你 NEED // end if 东西，你可能编码错误，而我不 NEED它，但我确实发现它更容易阅读。叫我老式的，强迫症，什么的。

【讨论】：

【解决方案7】：

垂直空间通常比水平空间更重要，因此过大的间距通常不是一个好主意。我确实认为用单个空行在逻辑上分隔代码块是个好主意。

听起来你的老师大多是个混蛋。俗话说，“能者行，行者行；不能者在~~上StackOverflow~~教。” ;)

【讨论】：

我认为你在这里找到了位置：一个空行，没有更多了。

【解决方案8】：

我使用的行距与您非常相似。我在现实世界中发现的代码往往布局相似，或者至少不会挤在一起以至于无法阅读。

【讨论】：

【解决方案9】：

除非您对垂直间距感到疯狂，否则我认为分离代码没有问题。我知道人们喜欢折腾使用小方法的想法，但即使你的方法只做一件事情，那件事情也可能需要大量代码才能完成。并非所有事情都可以在一屏代码中完成。

【讨论】：

【解决方案10】：

你的老师可能说对了一半，在现实世界中你不会有行距。当然，在 Big Ball of Mud 代码库中，如果你得到一个行空间，更不用说解释注释，我会很幸运。

顺便说一句，编写这个 Big Ball of Mud 大部分内容的 73 岁程序员仍在那里工作，他的解释是二进制文件需要保持尽可能小，我没有费心去检查编译器是否20 到 30 年前的效率低下，他们无法去除空格，但我有点怀疑。

我在自己的代码中使用单个空行来分解逻辑部分，因为我发现它大大提高了可读性。

对于这类可读性问题，最好的测试总是抓住一些你写的、一年多没看的棘手代码，看看你能不能快速掌握它。如果可以，那么您的代码将比您在现实世界中看到的大多数代码更好！

【讨论】：

听起来像那个 73 岁的老人 a) 不知道编译器是如何工作的，b) 没有注意“过早的优化是万恶之源”的原则。
当我在 TRS-80 上编写 BASIC 时，解释器基本上没有进行任何预处理，因此空格对性能造成了影响。从字面上看，从那以后我使用的每个系统都进行了某种预处理，因此空格不会减慢执行速度或增加可执行文件的大小。

【解决方案11】：

我将代码视为一篇文章。你有没有试过阅读两页没有段落或行距的文章？

我同意你的观点，逻辑组之间没有行间距简直是疯了。

【讨论】：

【解决方案12】：

我的一位老师降级了我的一项任务，因为我有在逻辑上间隔我的代码。他说， '当你必须整天阅读代码时现实世界，你不会有这个行间距，你会感谢我。”

除非你用 5 行或 10 行空格分隔块（这会让任何人发疯），否则你的导师就是个混蛋。

编码标准并不是一成不变的，而且对于所有软件商店来说，它们当然也不一样。所有公司都有不同的编码标准。值得一提的是，我公司的一些编码标准明确指出“使用单个空行在视觉上分隔逻辑相关的代码块”。

虽然我们应该努力不编写 200 行长的方法，但我们所有的短方法包含多个控制流元素仍然很常见，我们应该理解垂直空格与水平空格一样重要可读性。即使在同一方法中的 for 循环和 if 语句之间放置一个空行，也可以满足“单一方法，单一目的”的原则。

[编辑添加] 还有一些 cmets：

1）这个帖子里的几个人假设OP正在编写200行方法，或者在添加空行和编写草率方法之间存在必要的关联，这是非常冒昧的。

2) 不管它的价值是什么，而 OP 的讲师假设他的编码标准在任何地方都是相同的，这是完全错误的。但是，您应该将编程课程视为拥有自己标准的小型软件商店，因此您的代码应该以遵循这些标准的方式编写。

如果您的教师根据您的代码是否符合编码标准对您进行评分，那么请坚持获取标准列表。我知道如果我的成绩因为不符合教师从未给过我的标准而被扣分（或者如果他的标准说“用他们的数据类型为变量添加前缀”），脑袋就会滚动。

【讨论】：

【解决方案13】：

我一直在编写一些相反方向的代码；每个语句与下一个语句由一个空行分隔。作者还喜欢使用在第 60 列右对齐的四行注释，而不是在代码级别缩进的一行注释。它很难阅读，而且修复起来也很乏味。代码的另一个特性（C 代码），前一个 case 的 break 被“附加”到下一个 case，但是 case 后面有一个空行，将它与它的代码分开。咳！

代码块周围的空白行是好的。在一个函数中没有太多的代码块是好的。每行代码周围的空行令人不快。好事太多或太少都是坏事。

【讨论】：

我的想法完全正确。我们有一个（前）程序员编写的代码，完全符合您的描述，“每行代码之间的空白行”确实很烦人，对任何人都没有帮助。

【解决方案14】：

我们有一个编码标准，规定我们不应在一行中放置多个空行。其他的都取决于开发商。在实践中，我们按照您说的做 - 尝试将逻辑连接的线分组并用空行隔离它们。

【讨论】：

【解决方案15】：

用小方法，为了有一个低cyclomatic complexity。方法的圈复杂度高一般意味着你的方法必须分成几个其他的子方法，这样会更容易阅读，也更容易测试！

我认为您的代码正面临这种问题。

一般100+行的方法太大太复杂，必须重构。

总而言之，不要用行空间来分解代码，而是将其分解为单独的方法......

【讨论】：

圈复杂度没有考虑有时有用的大而愚蠢的案例类型语句。它们的 C.C. 很高，但很容易理解。

【解决方案16】：

空格有助于使您的代码更具可读性，我认为这里的共识是它们在很大程度上并不是一个坏主意。但似乎没有人指出，与空行一起，注释可能不会出错。

/* This section preps the widgets for display */
block 
of some 
code

/* This section passes the widgets to the display handler */
and 
so 
on

请记住，大多数代码会在其生命周期内被多次阅读，因此您可以采取任何措施让未来的维护者的生活更轻松，这将是一个很好的加分项。

【讨论】：

【解决方案17】：

1) 我同意你关于行距的观点

2) 在我的办公室里，行距很少，因为“这样你可以在一页上看到更多的代码”。他们还将多个语句放在一行上，并且（恕我直言）使用 ?:... 我讨厌它。

3) 我不同意“这就是他是老师的原因”这句话。作为一名（前）老师，我不得不说，在我取消放置空间的分数之前，我会因为没有在部分之间放置空间而降级。我想我也没有。我的观点是，他是个混蛋与他是个老师是正交的。（编辑：该部分已从原件中编辑，但我将其留在这里以保持 3 的规则......）

不要诋毁老师！

【讨论】：

【解决方案18】：

我知道这是一个老问题，但我在搜索其他内容时绊倒了它，并有一个观察结果：查看现有答案。它们通常很短，但包含空行。

这就是段落。就像在写作中一样，线条是一种快速、直观的方式来分离概念。这并不意味着上面的每一段都应该分成一个单独的答案；这并不意味着每个代码“段落”都应该被分解成一个单独的方法。

这是一个愚蠢的抱怨。如果仍然可以与那位教授交谈，我会解释“文字墙”的含义。

【讨论】：

【解决方案19】：

在我看来，在您的代码中添加一个空格暗示您应该将您的函数拆分成更小的部分。通过添加空格来清理代码比一英里长的未分隔行列表更可取。通过分离出较小的函数来清理代码会更好。

【讨论】：

Hrm... 那么在函数开头声明变量之前和之后添加一个空行表示它们应该在一个新函数中？我不这么认为。
我不同意这一点。如果一个函数/方法变得太长包括空行，那是一种气味。省略空行以在垂直空间中填充更多内容也是一种味道。
单一目的是比空行更好的指南，但是当您将一个目的添加到逻辑上分离的功能时，它们是一个非常好的提示。 :)
把这个放回0，虽然我不完全同意这个评论，但我认为至少有一些真实感，不认为它应该得到-1。
@treant：如果你在函数的开头声明了这么多变量，以至于你觉得有必要将它们分开，这是另一个暗示你的函数太大了。

【解决方案20】：

我不会开始建议任何细节。这里和互联网上的其他地方有很多很好的建议。

但我会说是一致的。至少在一个应用程序或模块中——因为我知道我会不时改进我的方法，但我会尽量让所有代码在同一个地方看起来都一样。

如果您始终如一，任何其他开发人员都很容易选择您的节奏和风格。

【讨论】：

【解决方案21】：

听起来并不自命不凡，但我认为代码中的空白行与乐谱中的短语标记或诗歌中的换行符具有相似的功能：它们在不改变内容语义的情况下向读者传达意图。

这是我刚刚从项目中复制粘贴的方法：

public static void Startup(bool startupUser)
{
    URI = "";
    AutoComplete = new AutoCompleteWrapper();
    SessionToken = Guid.Empty;
    ExternalDataSetLock = new object();

    ConfigDS.Init();
    CalendarDS.Init();
    CalendarDSBuilder.Init();

    if (startupUser && UserName != null)
    {
        string autoCompleteFilename = Path.Combine(UserFolder, "autocomplete.xml");
        AutoComplete.Load(autoCompleteFilename);
    }
}

这里的空行有什么作用？他们阐明了在这种方法中基本上发生了三种不同类型的初始化。如果我添加一个需要在启动时初始化的新属性，我知道我将把初始化它的行放在哪里。空白行还暗示了如果这个函数的大小翻倍，我打算如何重构它。

使用空行的风险与任何其他类型的隐含含义的风险相同：它是隐含的。您在编写代码时所暗示的含义可能不是阅读代码的人所理解的含义。

但是请原谅，我们没有理由不使用它们。

【讨论】：

【解决方案22】：

我已开始遵循此处的 Microsoft 设计指南：

Design Guidelines for Class Library Developers

【讨论】：