在我当前的项目中,我们总是在java源文件的末尾插入空的新行.我们还使用CheckStyle(具有错误级别)强制执行此操作.
我很长一段时间都在寻找这个话题,但不幸的是我找不到任何令人信服的理由.似乎其他开发人员对此非常漠不关心,因为他们只是在eclipse格式化程序中选中了一个复选框,并且它是自动完成的.但我仍然不知道为什么需要它,为什么它可能很重要).所以我的问题是:
为什么Java源文件末尾的空行需要?它是当前的需求还是过去的遗留物,在目前的代码库中是不可取的?
Ber*_*t F 31
我认为他们正在努力确保每个文件都以尾随的换行符结尾.这与以空行结尾(即空行换行)不同.
编辑:正如@Easy Angel在评论中简洁明了:尾随换行="\n"和空白行="\n \n"
我想要么:
你的主管是强制要求每个文件以换行符结尾,但是它被误解为强制每个文件以空行结束(即以换行符结尾的空行),否则
他们试图通过实际强制每个文件以空行(也就是以换行符结尾的空行)来确保每个文件以换行符结尾,从而确保文件以至少一个换行结束(并且可能是冗余的额外换行符 - 过度杀伤?).
除非编辑器实际显示换行符号,否则在某些编辑器中并不总是清楚一个文件:
我认为大多数现代源代码编辑器都会插入一个尾随换行符.但是,当使用较旧的更通用的编辑器时,我总是会尝试确保我的源代码文件(以及一般的文本文件)总是以尾随换行符结束(偶尔会出现一个空白行/空换行符,具体取决于我所使用的编辑器)使用)因为:
当cat用于在命令行上显示文件时,如果文件缺少尾随换行符,则下一个输出(如shell提示符或脚本可能在文件之间输出的可视分隔符)最终会出现在最后一个非换行符后面而不是从换行开始.通常,尾随换行使文件更易于用户和脚本.
我相信如果文本文件缺少一个编辑器(我记不清任何细节)会自动插入一个尾随换行符.这会使文件看起来像是被修改过的.如果您在不同的窗口中打开一堆文件然后关闭所有文件会让您感到困惑 - 编辑器会提示您保存,但您不确定是否对文件进行了"真正的更改",或者只是自动修改了插入换行符.
一些工具diff和一些编译器会抱怨缺少尾随换行符.这是用户和工具可能需要处理的更多噪音.
编辑:
关于编辑器添加换行符并且无法查看文件末尾是否有换行符与空白换行符,我刚刚测试了Vim,Eclipse和Emacs(在我的Windows系统上使用Cygwin):我打开了一个新文件,输入'我没有按[ENTER]保存并保存.我检查了每个文件od -c -t x1.
但
你喜欢解释.
我个人的做法是尝试确保文本文件以尾随换行符结尾.我只是觉得人们和工具最不出意外就是这种情况.在这方面,我不会将源文件与文本文件区别对待.
谷歌出现了这个:
这个编辑,显示了关于来自C编译器,svn(因为差异),差异等缺少尾随换行的警告的点击.我觉得有一般期望文本文件(包括源文件)以当他们倾向于在那里时,一个尾随的换行线和最不令人惊讶的(并且不那么嘈杂).
最后这很有趣:
清理没有尾随换行符的
文件文本文件的所有行都应该换行换行符(即\n).这是由POSIX声明的,即文本文件是包含组织为零行或多行的字符的文件.
反过来,行被定义为
*零个或多个非字符加上终止字符的序列.
但是,所有这一切,这只是我个人的做法.我很高兴与任何要求的人分享我的观点,但我不会强迫任何人这样做.我觉得这不值得强制,就像我在这里说的那样:
虽然我是一个一致的人,但我也反对微观管理每一种风格.拥有大量的编码约定,特别是当其中一些似乎是任意的时,是阻止人们遵循它们的一部分.我认为编码指南应该简化为提高功能的最有价值的实践.通过强制实施这一做法,可读性,可维护性,性能等提高了多少?
L. *_*nda 23
这是在最后有额外换行的一个很好的理由:
如果你有一个没有换行符的文件,那么下次编辑文件以添加另一行时,大多数合并工具会认为现有的行已经改变了(我90%肯定SVN也这样做).
在下面的示例中,包含"编辑前的最后一行"的行没有换行符.如果我们尝试添加新行"编辑后的最后一行",我们可以看到第5行和第6行都标记为已更改,但两个版本中第5行的实际内容相同.

如果每个人都遵循您的项目主管建议,那么这将是结果(只有第6行与原始文件不同).这也避免了合并期间的误解.

虽然这可能看起来不是什么大问题,但是假设一个开发人员(A)实际上意味着改变最后一行的内容而另一个开发人员(B)添加了一个新行.如果在EOF之前没有使用换行符,则会出现合并冲突,因为开发人员B也被迫编辑前一行以添加换行符.并且...谁喜欢CVS/SVN冲突?
| 归档时间: |
|
| 查看次数: |
25173 次 |
| 最近记录: |