为什么建议在源文件的末尾使用空行？

如果文本文件中的最后一行数据未以换行符或回车符/换行符组合结尾，则许多旧工具会出现异常行为。他们忽略该行，因为它以 ^Z （eof） 结尾。

除了当您在文本编辑器中移动到文件末尾时，它是一个更好的光标位置。

在文件末尾使用换行符可以简单地检查文件是否未被截断。

文件末尾出现空行，以便输入流的标准读取知道何时终止读取，通常返回 EOF 以指示您已到达末尾。大多数语言都可以处理 EOF 标记。出于这个原因，从过去开始，在 DOS 下，EOF 标记是 F6 键或 Ctrl-Z，对于 *nix 系统，它是 Ctrl-D。

大多数（如果不是全部）实际上会直接读取 EOF 标记，以便运行时库从输入读取的功能将知道何时停止进一步读取。当您打开“追加”模式的流时，它将擦除 EOF 标记并写入它，直到显式调用关闭，它将在该点插入 EOF 标记。

较旧的工具期望有一个空行，后跟 EOF 标记。如今，工具可以处理空行并忽略它。

某些语言根据输入行来定义其输入文件，其中每个输入行都是一系列以回车符结尾的字符。如果它们的语法是这样定义的，那么文件的最后一行也必须由回车符终止。

此外，当您修改文件并在文件末尾附加一些代码时 - diff（至少在标准配置中是 git diff）将显示您更改了最后一行，而您实际执行的唯一操作 - 添加了换行符。因此，简历报告变得不那么方便了。

如果您尝试将两个文本文件连接在一起，如果第一个文件以换行符结尾，您会更满意。

如果按照与为什么列表中允许尾随逗号相同的推理追加到文件，也可以为更干净的差异提出参数？

以下内容是从链接的资源中复制（并修剪了一点）：

改变：

s = [
  'manny',
  'jack',
]

自：

s = [
  'manny',
  'jack',
  'roger',
]

仅涉及差异中的一行更改：

  s = [
    'manny',
    'jack',
+   'roger',
  ]

当省略尾随逗号时，这击败了更令人困惑的多行差异：

  s = [
    'manny',
-   'jack'
+   'jack',
+   'roger'
  ]

这是因为文本文件的定义。在任何 unix 环境中创建新文本文件时，该文件的内容是换行符“\n”

否则，文件不会真正标识为文本文件。现在，一旦我们向这个文本文件添加代码，它就不要删除这个定义文本文件本身的初始换行符。

这个问题，以及大多数现有的答案，似乎都是基于一种误解。

通常称为“换行符”（C中的U+000A换行符）的ASCII控制字符不会开始（Unix样式）文本文件的新行。它结束文本文件的当前行。如果文本文件的最后一个字符是 U+000A，则 U+000A 和文件系统的 EOF 标记之间没有空行（但已实现）。相反，如果（非空）文本文件的最后一个字符不是 U+000A，则该文件的最后一行尚未结束，因此称为“不完整”。\n

通过一些示例，这可能会更清楚：

此文件包含两行完整的文本。它不包含第三个空行。

$ printf 'first\nsecond\n' | xxd
00000000: 6669 7273 740a 7365 636f 6e64 0a         first.second.

此文件包含第三个空行。

$ printf 'first\nsecond\n\n' | xxd
00000000: 6669 7273 740a 7365 636f 6e64 0a0a       first.second..

这个文件只包含一行完整的行，加上第二行不完整的行。

$ printf 'first\nsecond' | xxd
00000000: 6669 7273 740a 7365 636f 6e64            first.second

有时，您想要一个不完整的最后一行 - 例如，在PHP脚本的末尾和EOF之间有一个换行符，可能会导致额外的空格在错误的位置发送到渲染的HTML中（我会链接到具体的例子，但我今天早上没有运气找到一个）。因此，优秀的文本编辑器会在他们的 UI 中清楚地区分上述三种情况。?>

但是，较旧的文本处理工具经常无法处理不完整的最后一行。例如，某些实现不会将不完整的最后一行计为一行，而某些实现将默默地将换行符添加到不以 1 结尾的文件中，无论您是否愿意。因此，只有当您有特定原因需要它们时，才应该使用不完整的最终行。wcvi

（注意：据我所知，我刚才所说的一切都适用于DOS样式的文本文件，其中双字节控制序列U+000D U+000A用于结束一行，而不仅仅是U+000A。