我在这个问题上的意图不是迂腐，而是探索一个重要主题（空白的使用）的一个被忽视的轴。在使用水平空格、在条件后缩进、if 和括号之间的空格等方面已经进行了很多辩论和关注。事实上，这个问题被认为是如此重要和有争议，以至于一些公司不仅有规则和标准，但有些公司甚至有禁止讨论的规则。
考虑到水平空白的状态，为什么对垂直空白的讨论是一个死问题？为什么x比y更重要？前几天注意到，我在阅读代码时，经常会不假思索地调整语句的垂直分组。现在阅读了其他人的代码，着眼于垂直空白，我注意到了几种模式，所以我问 stackoverflow：
我看待代码中的垂直空间就像看待书面散文中的段落一样。正如段落旨在将具有共同点或想法的句子组合在一起一样，相关的行也应该组合在一起。
总体目标是提高代码的可读性。就像没有任何段落的文章很难阅读一样，没有任何垂直空间的代码也是如此。就像散文一样，在撰写太短或太长的段落之间存在平衡。但最终，它主要归结为个人风格和偏好。
我认为最重要的事情之一是将逻辑步骤组合在一起，例如：
foo.setBar(1);
foo.setBar2(2);
foo.writeToDatabase();
bar.setBar(1)
bar.setBaz(2);
bar.writeToDatabase();
这样，代码更容易阅读，而且对我来说更具描述性。
如果一组语句在逻辑上相关，我给它前后各空一行。如果我稍后需要将其重构为函数，这种分离会有所帮助。
至于双空行：如果有那么明显的东西，你真的应该考虑把它变成一个函数。
如果注释适用于多行代码，那么我会在这些行的最后一行之后放置空格，除非有其他语法可以将其分解（例如块的结尾）。
任何我正在做“某事”的地方都需要几行代码，紧接着是“其他事情”，然后我要么抽象成单独的函数，要么放置注释[*]。因此，代码行通常以短块组合在一起，除非流程控制使其（在我看来）不言自明。
我确实有点关心空白，但实际上我更关心的是评论。如果几行代码一起做了一些特定的事情，并且它没有被作为一个函数取出，那么我想看看那个东西是什么的英文描述。这样我就可以看到函数的“步骤”真正加起来是正确的结果，然后看看每个步骤都做了它声称要做的事情。
在类中，我有时会在方法/成员函数之间放置空格，有时则不会。在 C++ 中，我在访问说明符之前放置了空格。
我在类之间（有时不适用于 Java 中的匿名内部类）和类外的函数之间放置空格。
除此之外，我的代码在垂直方向上非常密集。我几乎从不使用多个空行，即使在分隔头文件等的部分时也是如此。我更喜欢blankline-commentline-blankline 而不是blankline-blankline，即使注释行最终成为完全平庸的东西，如“辅助函数”。我不喜欢函数之间有巨大垂直空白的样式 - 如果它们是如此分离以至于你不想同时在屏幕上看到它们，我会说要么将它们放在不同的文件中，要么用 Doxygen 填补空白/Javadoc 注释。
[*] 在我签入的版本中。我通常编写或多或少没有注释的代码，然后编译它，运行快速测试，注释它，运行适当的测试，提交它。这通常会改变一点，有时会改变很多。例如，如果我正在对预先精确定义的算法进行编码，或者对实现“显而易见”的规范进行编码，我可能会先写注释，然后再写代码。
几十年来，众所周知，程序员理解代码的能力通常受到他一次能看到多少代码的限制。（例如，参见 Weinberg，“Psychology of Computer Programming”，一个古老但很好的东西。）在纸质列表的旧时代，程序员会抓取大表并展开多页列表。如今，屏幕空间比 24x80 时代要好一些，但我仍然倾向于尽量减少垂直空白的使用，因为大量空白行占用了可能显示实际代码的屏幕空间。
我当然关心并倾向于在适当的地方用空行正确地对代码进行分组（至少对我的眼睛而言）。通常这意味着很多空白行，但总的来说，我认为代码比所有内容都挤在一起更清晰。就像运算符周围的空格是一件非常好的事情一样，逻辑分组语句周围的空白行也是如此。
不过，同时有多个空行看起来有点不合适。
如果代码垂直间隔不规则，我发现很难阅读。我什至会删除不需要的大括号，或者如果是短块，例如 ifs 或 fors，则将其放在同一行。