156

如果您在您选择的 IDE 中启用“查看右边距”，它可能会默认为 80 个字符。我倾向于将其更改为 120，除了这是我几年前所在公司的标准之外，没有其他公司告诉我这样做不同。

我的问题是，是否有任何研究实际上表明 80 个字符是代码可读性的最佳最大宽度，或者这个值只是“它一直都是这样”并且没有人真正知道为什么会这样？而且，一行代码的宽度是否应该成为您的编码标准的一部分？

4

11 回答 11

131

实际上，80 列的东西早在DOS 之前。它来自卡片打孔器，它是 80 列设备。

为了回答 OP 的问题，一项“研究”已经进行了大约 600 年——印刷书籍。这些已经发展了几个世纪，最重要的是可读性，到我们现在的位置，文本的平均行长约为 60 个字符。因此，为了可读性，请选择更窄的边距。

于 2009-02-23T15:47:02.703 回答
130

请怜悯那些必须在以后维护您的软件并遵守 80 个字符限制的程序员。

喜欢 80 的理由：

  • 在笔记本电脑上使用更大的字体可读

  • 留出空间将两个版本并排放置以进行比较

  • 在 IDE 中为导航视图留出空间

  • 打印时没有任意断行（也适用于电子邮件、网页……）

  • 将复杂性限制在一行

  • 限制缩进，这反过来又限制了方法/函数的复杂性

是的，它应该是编码标准的一部分。

于 2009-02-23T16:38:29.460 回答
46

我没有学习，但我会谈谈我的经历。

我发现在处理文本时水平滚动很乏味。我查看代码将在其中使用的环境，并根据该上下文设置宽度标准。

例如，当我在 XWindows 上的 Emacs 中工作时，始终有 2 个 Emacs 窗口并排运行非常好。这将它们限制为 80 个字符，所以这是我的最大行长。

有一次，我在 1920x1200 屏幕上的 Visual Studio 中工作。我会保持它最大化，所有工具窗口都停靠在一侧。两个编辑器窗口留有足够的空间，大约 100 个字符。

我还发现最长的行来自具有长参数列表的方法调用。这有时是一种代码异味：也许该方法应该被重构。

如果您和您的合作程序员拥有高分辨率的屏幕和敏锐的视力，请务必使用小字体和长行。相反，您可能需要短线。

于 2009-02-23T15:53:25.667 回答
34

除非公司另有说明，否则我通常使用 120-150。但是，它也取决于代码的类型：

  • 我（几乎）从不在一行上使用多个语句
  • 仅当看起来相似的线条可以对齐且不中断时，我才使用长线条 (>12)。
  • 我总是使用足够的空格/括号等
  • 我更喜欢较长的变量名称而不是较短的名称

直到几年前，我限制在 100 个，但现在通常使用宽屏，甚至可以在笔记本电脑上看到 120 个高分辨率显示器（我几乎不使用）。

将屏幕比作一本书并不是很好，因为一本书有更多的垂直空间，而屏幕有更多的水平空间。我总是尽量保持函数最大值。一个可见的屏幕长。

于 2010-03-19T16:20:47.800 回答
9

也许 80 个字符也是避免这些不良 getter 链的好点：

object.getFoo().getBar().getFooBar().get ...

如果将其限制为 80 个字符，也许有人会本地化这些变量并进行空值检查等，但也许大多数程序员会让它们换行。我不知道

除此之外，正如starblue所说，80个字符很棒。这应该明确地进入编码标准。

于 2009-08-05T05:45:57.020 回答
8

忽略硬件限制，以及我们阅读代码与自然语言的方式的任何差异，我认为将行限制在 80 个字符左右的三个主要原因。

  1. 人的眼球是圆的，不是很窄很宽，大部分分辨率都在中间。一次阅读数小时时，根据需要使用一个滚动条以短弧扫视会更舒服。我不知道针对代码易读性的正式研究，但根据我自己的观察，显示器距离 2 英尺，文本大小为 10pt 等宽字体，100 个字符约占我水平字段的 1/3视力，或大约 60 度（在我们所有眼睛的分辨率所在的 30 度左右之外）。
  2. 大多数人在工作中使用大型显示器，这样他们就可以看到多个东西而无需来回点击，而不是让他们可以看到一件非常大的东西。
  3. 较短的行包含较少的复杂性，这有望迫使开发人员将他们的代码分解成更易于消化的单元。
于 2016-09-29T18:06:12.610 回答
3

我清楚地记得在某处（我认为是在敏捷文档中）读到，为了获得最佳可读性，文档的宽度应该大约是两个字母或 60-70 个字符。我认为旧终端的线宽部分来自旧的印刷规则。

于 2009-02-23T15:54:26.507 回答
3

如果您要打印代码，右边距选项旨在向您显示页面的宽度，并且之前发布过说它设置为 80，因为这是在 GUI 之前一直到打孔之前的历史行长牌。

我最近在某个博客上看到了一个建议（不记得是哪个博客了），以增加 IDE 字体大小以提高代码质量，其背后的逻辑是，如果屏幕上适合的代码越少，你就会写出更短的行和喊话功能。

在我看来，较短的行使阅读代码和调试变得更容易，所以我尽量保持行短，如果你必须设置一个限制来让自己写出更好的代码，然后选择适合你的——如果你更有效率的话更长的行可以随意增加页面大小和代码只在宽屏幕上。

于 2009-02-23T15:55:09.440 回答
1

正如有些人在其他答案中指出的那样，限制 80 个字符的原因部分是历史性的（打孔卡、小屏幕、打印机等），部分是生物性的（为了跟踪你所在的行，能够看到整个线无需转头）。

也就是说，请记住，我们仍然是人类，我们构建工具来解决我们自己的局限性。我建议你忽略关于字符限制的整个争论，只写有意义的东西，不管它们的长度如何，并使用可以帮助你正确跟踪行的 IDE 或文本编辑器。在制表符与空格的辩论中使用相同的缩进参数，以及缩进的宽度我建议您使用缩进标记（最常见的是制表符）并让人们配置自己的 IDE 或文本编辑器来显示它们因为他们觉得最舒服。

坚持每行固定数量的字符总是会让除了目标受众之外的所有人都变得更糟。也就是说，如果你永远不会分享代码，永远；那么真的没有理由开始这个讨论。如果您想共享代码，您可能应该让人们自己决定他们想要什么，而不是将您（或其他人）的理想强加给他们。

于 2014-05-20T18:58:50.540 回答
0

据我所知，80 个字符用作编码标准，以保持与命令行编辑器的兼容性（默认终端宽度通常为 80 个字符）。对于现代 IDE 和大屏幕分辨率，80 个字符可能不是“最佳”，但对于许多开发人员来说，在终端中保持可读性是必不可少的。出于这个原因，80 字符宽度不太可能很快被替换为代码宽度的事实标准。为了回答您的最后一个问题，是的，代码宽度以及任何其他会影响代码可读性的特征都应该在您的编码标准中得到解决。

于 2009-02-23T19:38:45.267 回答
0

这里有一个研究供你参考：

我教编程 30 多年，在此期间，我积累了 1823 个 C 源代码和各种例程，从随机小游戏到神经网络、编译器、教育软件、自动生成的 lex/yacc 源代码等。

根据帕累托原则，这些程序中有 80% 的行数小于 159 列。因此，要削减较低的 20% 和较高的 20%，我们有：

  • 1823 源代码
  • 其中 80% 小于 159 列
  • 其中 80% 大于 64 列

现在这是一个给你自由的范围。您不想仅仅为了它而将代码限制为 80 列，因为有时您需要嵌套循环、函数或一些在更大的行中易于理解的缩进，并且如果您强行扭曲您的逻辑要适合任意列宽，您没有使用最佳逻辑。

另一方面，有时线条的大小表明您的逻辑可能会更好，而线条可能会更小；特别是如果您不在代码的嵌套部分中并且您已经超过了 160 列的限制。

根据我自己的经验和可读性，我建议您编写代码的目标是 80 列，但最多允许 120 列边距，并且永远不要超过 160 列的限制。

此外，我们应该考虑存在的较早的阅读体验：书籍。书籍的排版是为了方便读者的眼球运动，根据该领域的专业人士的说法，最好的列大小是每行 60 个字符左右，不少于 40 个，不超过 90 个。

由于编码并不完全是阅读一本书，我们可以达到上限，我们应该保持在每行 80 到 90 个字符之间。

除非您正在编写将在特定屏幕尺寸和旧显示器上运行的低级代码，否则我建议您遵循gopher标准，即每行 67 个字符。

好奇心：

  • 1823 源代码中最大的一行是一行1020 列的五行
  • 不是单行的最大代码行是一个文字冒险游戏，有 883 行。当然这是一个很好的做法，因为如果你不限制换行，文本会更好地显示在你的屏幕上，在你实际拥有的列中换行。
  • 最小的代码行（非零）是 14 个字符长。
  • 我用来检查文件大小的命令是：find . -type f -name "*.c" -exec wc -L {} \; | sort -n | less -N
于 2022-02-19T05:33:51.107 回答