我认为他们正在尝试确保每个文件都以尾随换行符结尾。这不同于以空行（也称为空换行符）结尾。
编辑：由于@Easy Angel在注释中简洁明了：尾随换行符=“ n”和空白行=“ n n”
我认为：
您的线索要么要求每个文件都以换行符结尾，要么被误解为要求每个文件都以空行结尾（即以换行符结尾的空行），否则
他们试图通过强制每个文件以空行结尾（又名以换行结尾的空行）来确保每个文件都以换行符结尾，从而确保文件以至少一个换行符结尾（并且可能多余的其他换行符-过度杀伤） ？）。
除非编辑器实际显示换行符，否则在某些编辑器中并不会始终清除文件：
- __根本 不结束 换行符，
- ENDS 与单个结尾的新行，或
- ENDS 的空白换行符，即2个尾随的换行符
我认为大多数现代源代码编辑器都会在末尾插入换行符。我将始终确保我的源代码文件（和一般的文本文件）始终以结尾的换行符结尾（根据我当时的编辑器的不同，偶尔会以空白行/空换行符出现）使用），因为：
但是，当使用较旧的更通用的编辑器时，
当
cat
用于在命令行上显示文件时，如果文件缺少结尾的换行符，则下一个输出（例如，shell提示或脚本可能在文件之间输出的视觉定界符）将最终出现在最后一个非换行符之后而不是从换行符开始。通常，结尾的换行符使文件对用户和脚本更友好。我相信某些编辑器（我不记得任何细节）会在文本文件缺少后缀时自动插入尾随的换行符。这将使其看起来像文件已被修改。如果您在不同的窗口中打开了一堆文件然后关闭所有文件，将会引起混乱-编辑器会提示您保存，但不确定是对文件还是对文件进行了“真正的更改”插入换行符。
有些工具（例如
diff
和一些编译器）会抱怨缺少尾随换行符。这是用户和工具可能必须应对的更多杂音。
编辑：
关于编辑者添加换行符而又看不到文件末尾是换行符还是空白换行符的问题，我刚刚测试了Vim，Eclipse和Emacs（在Windows系统上使用Cygwin）：我打开了一个新文件，键入“
h”“ e”“ l”“ l”“ o”并保存，而无需按[ENTER]。我用检查了每个文件
od -c -t x1。
- Vim 确实 添加了尾随换行符。
- Emacs 确实 添加了结尾的换行符。
- Eclipse 没有 添加尾随换行符。
但
- Vim的 没 让我上下光标到“你好”下一个空行。
- Emacs 确实 允许我将光标向下移动到“ hello”下的空白行。
- Eclipse中 没有 让我上下光标到“你好”下一个空行。
随便翻译。
我的个人做法是尝试确保文本文件以尾随换行符结尾。我只是觉得情况确实如此，对人员和工具而言，这是 最没有惊喜
的。在这方面，我不会将源文件与文本文件区别对待。
Google证明了这一点：
在本次编辑中，其中的热门歌曲均谈到了有关C编译器，svn（由于diff），diff等导致的缺少尾随换行符的警告。我认为人们普遍希望文本文件（包括源文件）以尾随换行符，并且当它们趋向于出现时，就不会感到惊讶（且噪音较小）。
最后，这很有趣：
清理没有尾随换行符的
文件文本文件的所有行都应以换行符（即 n）结尾。这由POSIX声明，即文本文件是包含以零行或更多行组织的字符的文件。
反过来，一行定义为
*零个或多个非字符加一个终止字符的序列。
但是
，这只是我的个人习惯。我很高兴与提出要求的任何人分享我的观点，但是我不希望对此提出任何要求。我觉得这不值得强制执行，就像我在这里说的那样：
虽然我是一个全力以赴的人，但我也反对微观管理每一个样式。拥有大量的编码约定，尤其是在其中一些看起来有些随意的情况下，这是阻止人们遵循它们的一部分。我认为应该将编码准则简化为可改善-
ilities的最有价值的实践。通过强制执行此操作，可读性，可维护性，性能等有多少改进？
