在当今这个时代，对代码文件强制限制最大宽度为80个字符有合理的理由吗？

Question

说真的，对于一个22英寸的显示器来说，它只覆盖了屏幕的大约四分之一。我需要一些弹药来砍掉这个规则。

---

我并不是说就不应该有限制；我只是在说，80个字符太少了。

- TraumaPony

---

所有的回答基本上都说明了我想要补充的内容。为了给你一个真实的例子——我有一台x61s，分辨率是1024x768。当我在路上时，我没有我的高级显示器。当我的IDE中的代码超过这个规则时，打开它是很痛苦的。 - Till

可能是http://stackoverflow.com/questions/95575/的重复问题，当你编码时，你会为多少列进行格式化？ - Roger Pate

即使您有一组三个显示器，这也不是左右摇头的理由。永远不是。啊哈哈。实际上，眼睛移动得比头快。您知道报纸中的列吗？宽度的原因是为了方便眼睛/头部/人类。 - Ivan Black

相关帖子 - 为什么80个字符是代码宽度的“标准”限制？和关于最佳代码宽度的研究？ - RBT

更新于2021年12月13日：合并：Linux内核已正式弃用其编码风格，即代码行长度符合80列作为“强烈推荐的限制”。31-May-2020 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144 - Israr

Answer 1

我认为将代码保持在80（或79）列的做法最初是为了支持人们在80列哑终端或80列打印输出上编辑代码。这些要求现在大多已经消失，但仍有合理的原因保持80列规则：

• 避免复制代码到电子邮件、网页和书籍时出现换行问题。
• 并排查看多个源窗口或使用并排差异视图器。
• 提高可读性。狭窄的代码可以快速阅读，无需从左右两侧扫描眼睛。

我认为最后一点最重要。虽然在过去几年里，显示屏的尺寸和分辨率都增长了，但眼睛并没有。

- Will Harris

---

他们可能“在很大程度上消失了”，但并非完全消失。 我倾向于使用两种不同的设置：1）在连接到远程机器的ssh窗口中。默认情况下为80个字符宽。 2）在Visual Studio中，使用并排的两个面板，这样我就可以同时看到头文件和cpp文件。 - Enno

@steffenj: 实际上，书籍通常会力求每行大约66个字符（尽管这取决于其他参数而有所不同），因为更长的行确实会使阅读更加困难。最大的代码行长度可以有争议，但80在历史和实用方面都很方便。 - Steve S

限制每行长度会导致人们使用不太有意义的名称。 - Ian Ringrose

我觉得关于易读性的评论很有趣，因为我真正讨厌印刷编程文章/书籍等的是，用于代码示例的短行非常难以阅读。换行可能是有道理的，但分组应该在逻辑上进行，递归地剖析表达式，而不是因为输出设备偶然达到其限制。换句话说，我发现那些强加如此狭窄限制的设备并不适合显示代码。 - Chris Lercher

我认为80列代码强制规定的问题在于，他们忘记了代码也会沿着垂直方向增长。这会导致在垂直方向上出现同样的问题，并且当你不得不将单个语句分成两行或者甚至四五行时，现代代码看起来非常糟糕。这并不更易读。在现代代码中，我的意思是使用描述性变量名称和限定继承、命名空间、类等。请停止80列无意义的规定，改用常识。120更好一些，但也不应该成为规则。 - Larswad

Answer 2

80列文本格式的起源早于80列终端设备 -- IBM打孔卡片可以追溯到1928年，其历史可以追溯到1725年的纸带！这让人想起一个（失传的）故事，美国铁路轨距是由罗马不列颠战车轮宽度决定的。

我有时觉得有些约束，但有个标准限制是有意义的，所以就有了80列。

这是Slashdot也谈及的同一话题。

下面是一条老派的Fortran语句：

- therefromhere

Answer 3

在当今时代，80个字符的限制已经过时了。分割代码行应该根据实际需要，而不是按照任意字符限制。

- Craig

---

字符限制并不告诉你在哪里分割代码行，而是告诉你何时分割。 - gztomas

不，它并不是。如果你写的一行超过80个字符，那么你可能已经在表达复杂性或命名策略方面遇到了问题。正如其他人所提到的，可读性是最重要的考虑因素，而阅读速度在60-66个字符以上就会开始下降（基于人体生理学的排版）。 - sola

@sola 您的评论在此处出现，长度为98个字符，对我来说是一种密集的非母语语言，但完全可读。带有3-4个缩进、语法标记等的代码甚至更容易理解。 - dawid

@sola 这些研究与编程实际上没有任何关系，它们与英语中的普通文本（大多数情况下）有关。它们相当可疑，特别是考虑到它们与许多语言的基本工作原理相矛盾。更不用说它们是心理学领域广泛复制危机的一部分了。 - SacredGeometry

@sola 这种盲目支持错误科学的方式，好像它是事实一样，只因为有人写了一篇论文，而不是将其视为仅仅是流行的猜测，这种现象相当普遍。 - SacredGeometry

Answer 4

出于那些没有22英寸宽屏显示器的人的考虑，你应该这样做。个人而言，我使用的是17英寸4:3显示器，我觉得这已经足够宽了。但是，我也有三个这样的显示器，所以我仍然有很多可用的屏幕空间。

不仅如此，人眼在阅读超长行文本的时候，实际上会产生阅读难度。你会很容易迷失在哪一行。报纸大约有17英寸宽（或者类似），但你不会看到它们在整个页面上都写满了文字，杂志和其他印刷品也是如此。反而，如果保持每列的宽度较窄，实际上更容易阅读。

- Kibbee

---

如果加入缩进，情况就不同了。如果每个缩进使用4个空格，并且你处于这样的结构中：namespace->class->method->if->for，那么你已经用掉了五分之一的空间。 - TraumaPony

然而，阅读散文和阅读代码并不一样。 - Atario

+1 对于报纸来说非常好的例子。@Atario，阅读优秀的代码就像阅读散文一样。 - Todd Chaffee

@ben 所有的东西都在一行上，对吧？;-) - Todd Chaffee

@ToddChaffee 我刚才对你的比喻想得太深了哈哈。我继承的一些代码中的全局变量用于太多的事情，需要花费很长时间才能弄清它们来自哪里，或者它们在做什么，或者它们会对其他变量产生什么影响。如果它们是小说中的角色，那我会很享受这些东西。 - Ben

Answer 5

当您有一系列语句需要以轻微变化重复时，如果将它们分组成行，则更容易看到相似之处和差异之处，以使这些差异垂直对齐。

我认为以下代码比分割成多行后要易读得多：

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

更新：在评论中，有人建议以下是更简洁的方式：

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

虽然现在它适合80列，但我认为我的观点仍然成立，我只是举了一个不好的例子。它仍然表明，在一行上放置多个语句可以提高可读性。

- Sam Hasler

---

你所说的“从行到行只有细微差别”，也就是说，存在大量冗余代码。去除其中一些代码可以显著减少列数，而仍然保持垂直对齐。 - foraidt

我同意一般的想法，但是这个例子...那么这个呢： switch(...) { case ...BL: dxDir = - 1; dyDir = - 1; break; case ...BR: dxDir = + 1; dyDir = - 1; break; ... } ...["X"] = pt1.x + dxDir * Rad...X; ...["Y"] = pt1.y + dyDir * Rad...Y; - Yarik

我需要横向滚动第一组示例，这证明了短行更好的观点 :-) - Enno

我不明白为什么有人讨厌滚动？这是一种普遍的观点，我并不是说它是错的，我只是不理解。特别是如果你在代码编辑器中，你甚至不需要移动手到鼠标上 -- 只需使用 (ctrl+)arrow 或按下 end 键即可。 - KOGI

视野限制 - micrub

Answer 6

使用等宽字体在默认大小下打印（在A4纸上）是80列66行。

- Josh

Answer 7

我利用更大的屏幕优势来同时显示多个代码片段。

你从我这里得不到任何弹药。事实上，我不希望看到它被改变，因为在紧急情况下，我仍然会发现一些需要从文本控制台更改代码的情况比较少见。

- Twan

Answer 8

过长的行很难阅读。即使你的显示器可以同时显示300个字符，也不应该让文字行这么长。除非没有选择余地（需要一堆参数的调用），否则300个字符对于一个语句来说太复杂了。

我通常以80个字符为一般规则，但如果强制换行会导致不良位置的话，我会超过这个限制。

- Loren Pechtel

---

有研究表明，人们在阅读和跟随x个字符/单词之前会失去追踪。我认为80个字符/单词应该在其中。不过我没有任何支持这一说法的来源。 - Till

是的，我认为真正重要的不是保持代码行短，而是保持代码整洁、简明、易读和易懂。 - KOGI

如果你有一个（需要大量参数的调用），你无论如何都需要进行一些重构。 - Zarremgregarrok

@Zarremgregarrok 我曾经在微软的API中看到过一些非常长的参数列表。 - Loren Pechtel

@LorenPechtel 这是否意味着它写得很好？ - Zarremgregarrok

Answer 9

我唯一坚持保持80个字符以下的是我的注释。

就我个人而言，我将所有的脑力（虽然不多）都投入到编码中，如果在80个字符的限制下回头去把每一行都拆开的话，那真是很痛苦，因为我本可以花时间去写下一个函数。 当然了，Resharper 或许可以替我完成这项任务，但第三方产品更改我的代码布局并决定如何划分行数时，我会有点紧张（“请不要将我的代码分成两行 HAL，HAL？”）。

话虽如此，我们工作的团队规模相对较小，我们使用的显示器也比较大，所以不必太担心其他程序员的感受。

似乎，有些语言鼓励写长一点的代码以获取更高的效益（例如 if-then 语句的简写）。

- domus.vita

Answer 10

在Linux编码规范中，不仅要保持80个字符的限制，还要使用8个空格缩进。其中一部分原因是如果你达到了右边界，你应该考虑将一个缩进级别移动到一个单独的函数中。这样会使代码更清晰，因为无论缩进长度如何，带有许多嵌套控制结构的代码很难阅读。

- Ali

---

阅读有许多函数调用的代码怎么样？毫无疑问，在这两种方法之间有一个折中方案…… - Zsolt Török