我想这里的每个人都熟悉这句谚语,即所有文本文件都应该以换行符结尾。我已经知道这个“规则”很多年了,但我一直在想——为什么?


当前回答

我一直觉得,在解析一个没有结尾换行符的文件时,这条规则是很困难的。也就是说,您最终会编写代码,其中行的结尾由EOL字符或EOF定义。假设一行以EOL结尾比较简单。

然而,我相信这个规则是从需要换行符的C编译器派生出来的。正如“文件末尾没有换行符”编译器警告所指出的,#include不会添加换行符。

其他回答

基本上,如果没有得到最终EOL EOF,许多程序将无法正确处理文件。

GCC警告您这一点,因为它是C标准的一部分。(第5.1.1.2节明显)

“文件末尾没有换行符”编译器警告

很可能只是一些解析代码希望它在那里。

我不确定我是否会认为这是一条“规则”,而且这肯定不是我虔诚地遵守的。最明智的代码将知道如何逐行解析文本(包括编码)(任何行结尾的选择),最后一行是否有换行符。

的确,如果你以一条新的线结束:EOL和EOF之间(理论上)是否有一条空的最终线?一个值得思考的。。。

每一行都应该以换行符结尾,包括最后一行。有些程序在处理文件的最后一行时遇到问题,如果它不是换行符。

GCC对此发出警告,并不是因为它无法处理文件,而是因为它必须作为标准的一部分。

C语言标准说非空的源文件应以换行符结尾,换行符前不得紧跟反斜杠字符。由于这是一个“应”条款,我们必须发出一条违反此规则的诊断信息。这在ANSI C 1989标准第2.1.1.2节中。ISO C 1999标准(可能还有ISO C 1990标准)第5.1.1.2节。

参考:GCC/GNU邮件存档。

这源于使用简单终端的早期。换行符用于触发传输数据的“刷新”。

今天,不再需要换行符。当然,如果没有换行符,许多应用程序仍然存在问题,但我认为这是这些应用程序中的一个错误。

然而,如果你有一个需要换行符的文本文件格式,那么你可以得到非常便宜的简单数据验证:如果文件以结尾没有换行符的行结尾,那么你就知道文件已损坏。每行只有一个额外的字节,您可以高精度地检测损坏的文件,几乎不需要CPU时间。

一个单独的用例:当文本文件受版本控制时,提交卫生。

如果将内容添加到文件末尾,则先前是最后一行的行将被编辑为包含换行符。这意味着,打开文件以了解该行最后一次编辑的时间将显示换行符添加,而不是您实际希望看到的提交。

(该示例特定于git,但同样的方法也适用于其他版本控制系统。)