Norminette 空行或不在末尾

Question

为什么 VStudio 上带有 norminette 突出显示的人会在末尾添加一个空行。 当他们在 iTerm 中执行norminette时，它就可以工作

当您使用Vim并在末尾放置一个空行时，norminette会说Error extra line。

昨天和今天发生这种情况，我的 Vstdio 要求在末尾添加一行，当我在 iTerm 中执行 Norminette 时，它​​说错误额外一行。我回到 vim，删除该行并再次说错误以删除多余的行。我需要打开文件，添加行，然后删除并保存以使norminette工作。所以现在有时穆林内特在服务器上说“KO”，但我这边还好。当我在 vstdio 上工作时，我每次都需要添加/删除最后一行，

所以如果有人知道这个问题，我希望有一个更好的解决方案，而不是在接下来的 3 周甚至 3 年里仔细检查 vim

Answer 1

这个话题已经被讨论得死去活来了。

无论您使用什么系统，文本文件中的行通常以一两个不可见字符结尾。在某些系统上，它是一个“回车符”CR，后跟一个“换行符”LF，在其他系统上，它只是一个 CR，在在其他系统中，它只是一个LF，并且这只适用于最不奇异的系统。该字符或字符对有一些通俗的名称：“newline”、“EOL”等。从现在开始我将使用“EOL”。

现在，EOL 有两种语义解释。在某些情况下，EOL 被认为是“行终止符”，这意味着不对它后面的内容做出任何假设，而在其他一些情况下，EOL 被认为是“行分隔符”，这意味着总是有一个其后一行。

还有一个相关的问题是文本流应该如何结束。对于第一种解释，如果只是为了能够在两个流之间建立边界，那么流的最后一行应该以 EOL 结尾。根据上面的第二种解释，流的最后一行不应以 EOL 结尾，因为这意味着……最后一行并不是真正的最后一行。

因此，基本上，这段文本：

foo
bar
baz

可以编码为（第一种解释）：

foo<EOL>
bar<EOL>
baz<EOL>

或（第二种解释）：

foo<EOL>
bar<EOL>
baz

几十年来，大多数类 Unix 工具都采用第一种解释，并且通常期望最后一行 EOL，但许多更现代的工具已经采用了第二种解释，这给那些在 GUI 编辑器和 CLI 工具之间周旋的新一代人带来了很多困惑。

将一些带有最终 EOL 的文本提供给将其解释为“行分隔符”的工具，您会在文件末尾显示一条假想行：

1 foo
2 bar
3 baz
4

将一些没有最终 EOL 的文本提供给将其解释为“行终止符”的工具”，你可以得到任何东西，从合理的显示（如下）到响亮的抱怨（git）：

1 foo
2 bar
3 baz

加上像“newline”这样令人困惑的名字，你就会得到像这样永无休止的问题流的秘诀。

所以……这就是这里正在发生的事情：

1. 您正在使用以不同方式解释 EOL 的多种工具，
2. 您错误地解释了其中一种解释，
3. 并且根据这种误解采取了行动，结果令人困惑。

让我们一一解决这些问题。

1. 好吧，我们都这样做¯\_(ツ)_/¯。

2. 在现代 GUI 编辑器中，文件底部看起来像是额外的一行不太可能是额外的一行。它更有可能是第二种解释的产物。假设您使用的是某种类 Unix 系统，并且预期的 EOL 是 LF，您可以执行 $ xxd filename 以十六进制形式检查其内容：

   • 末尾有一个 a0 表示您的文件以 EOL 结尾，
   • 末尾的 a0a0 表示您的文件有一个额外的空行，
   • 末尾没有 a0 意味着它是由严格遵循第二种解释的编辑者编写的。

   第二种情况会让你的 linter 生气：

   错误：EMPTY_LINE_EOF（行：7，列：1）：文件末尾有空行
   

   但它似乎并不特别关心其他两种情况。

3. 因为您在 GUI 编辑器中看到文件末尾似乎是一个空行，但这并不意味着 a) 该行实际上存在以及 b) 您必须在文件末尾添加一个Vim 或任何其他编辑器。

   正确的做法是：

   • 让 Vim 做它开箱即用的事情，编写末尾带有 EOL 的文件，因为这是您的工具链（包括 Norminette）所期望的，
   • 设置您的 GUI 编辑器执行相同操作（即使它们仍然显示该假想线），
   • 删除项目中可能存在的任何无关的空行，
   • 切勿在文件末尾添加无关的空行，因为它充其量是无用的，充其量是被禁止的。