我想这里的每个人都熟悉这句谚语，即所有文本文件都应该以换行符结尾。我已经知道这个“规则”很多年了，但我一直在想——为什么？
当前回答
一个单独的用例：当文本文件受版本控制时，提交卫生。
如果将内容添加到文件末尾，则先前是最后一行的行将被编辑为包含换行符。这意味着，打开文件以了解该行最后一次编辑的时间将显示换行符添加，而不是您实际希望看到的提交。
（该示例特定于git，但同样的方法也适用于其他版本控制系统。）
其他回答
这源于使用简单终端的早期。换行符用于触发传输数据的“刷新”。
今天，不再需要换行符。当然，如果没有换行符，许多应用程序仍然存在问题，但我认为这是这些应用程序中的一个错误。
然而，如果你有一个需要换行符的文本文件格式，那么你可以得到非常便宜的简单数据验证：如果文件以结尾没有换行符的行结尾，那么你就知道文件已损坏。每行只有一个额外的字节，您可以高精度地检测损坏的文件，几乎不需要CPU时间。
我个人喜欢源代码文件末尾的新行。
它可能起源于Linux或所有UNIX系统。我记得有编译错误（如果我没弄错的话是gcc），因为源代码文件没有以空的新行结尾。为什么会这样呢。
现在已经很晚了，但我在文件处理中遇到了一个错误，这是因为文件没有以空换行结尾。我们使用sed处理文本文件，sed省略了输出的最后一行，这导致无效的json结构，并将流程的其余部分发送到失败状态。
我们所做的就是：
有一个示例文件，比如：foo.txt，其中包含一些json内容。
[{
someProp: value
},
{
someProp: value
}] <-- No newline here
该文件是在寡妇计算机中创建的，窗口脚本正在使用PowerShell命令处理该文件。一切都很好。
当我们使用sed命令sed的|value|newValue|g'foo.txt>foo.txt.tmp处理同一文件时
新生成的文件是
[{
someProp: value
},
{
someProp: value
和boom，由于无效的JSON，它使其余过程失败。
因此，用空的新行结束文件始终是一个好的做法。
我一直觉得，在解析一个没有结尾换行符的文件时，这条规则是很困难的。也就是说，您最终会编写代码，其中行的结尾由EOL字符或EOF定义。假设一行以EOL结尾比较简单。
然而，我相信这个规则是从需要换行符的C编译器派生出来的。正如“文件末尾没有换行符”编译器警告所指出的，#include不会添加换行符。
天啊，这是个人风格和观点的问题。
在过去，我没有写那句新语。保存的字符意味着14.4K调制解调器的速度更快。
稍后，我放置了换行符，以便使用shift+向下箭头更容易选择最后一行。
