更喜欢 windows 或 unix 行结尾的代码？答案

【问题标题】：prefer windows or unix line ending for code?更喜欢 windows 或 unix 行结尾的代码？
【发布时间】：2010-09-13 05:56:23
【问题描述】：

我编写的代码应该在 Windows 和 Linux 等 unix 上编译和运行。我知道行尾之间的区别，但问题是我的代码更喜欢哪个？有关系吗？我希望它保持一致 - 说我所有的代码只使用 LF，还是只使用 CRLF 更好？有比较标准吗？

如果最重要的话，我关心 C++ 和 Python 代码

【问题讨论】：

如果您正在使用现有代码，请使用它使用的任何内容 - 不要尝试对其进行大修 :) 如果没有，请参阅其他人的答案。

标签： c++ python multiplatform line-endings

【解决方案1】：

使用足够智能的版本控制系统来忽略签入时的行尾，并在签出时使用平台的正确值。

【讨论】：

+1。 svn propset svn:eol-style native <file>（或等效的 git 命令），并且您的版本控制软件将行结尾设置为您当前平台期望的任何内容。
“签入时忽略”是什么意思？存储库中究竟存储了什么？
@zaharpopov 这并不重要。关键是当您签出工作副本时，您的文件会得到正确的行尾。
“忽略”我的意思是如果唯一的区别是行尾，签入工具不会认为文件已更改，因此不会创建新版本（当然这仅适用于文本文件，如果您将文件标记为二进制文件，那么每个差异都很重要）。大多数工具通过规范化所有行尾来做到这一点，可能是 unix '\n'，但也有 diff 工具可以忽略 '\r' 差异以及其他空白更改。

【解决方案2】：

对于代码本身，没关系。所有相当现代的编辑器和编译器都可以处理这两者（我假设您没有使用记事本:-)）。使用主开发平台的行尾即可。

【讨论】：

不是记事本，但 Linux 上的许多编辑器将 CR 显示为 ^M，这很烦人
大多数编辑器仅在同一文件中有多个行尾时才会显示 ^M。
Xcode 是一种主要的编辑器，它在编辑带有 CRLF 行结尾的源文件时表现不正常。

【解决方案3】：

IME 最简单的方法是使用 *NIX 行尾。 Windows 的编译器和 IDE 可以很好地处理它，并且它是 *NIX 工具的本机。使用 DOS 行尾即使不是问题，也会给 *NIX 上的一些（甚至更流行的）文本编辑器带来不便。你经常会在行尾得到丑陋的'^M'，你必须明确地转换或告诉你的编辑器它有 DOS 行尾。

【讨论】：