最佳码宽研究？

事实上，80列的东西 早就有先例了DOS。它来自卡穿孔机，这是80列的设备。

为了回答 OP 的问题，一项“研究”已经进行了大约600年——印刷书籍。经过几个世纪的发展，我们已经把可读性放在第一位，现在文本的平均行长大约是60个字符。因此，为了提高可读性，应该缩小页边距。

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

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

例如，当我在 XWindows 的 Emacs 中工作时，在任何时候都有2个 Emacs 窗口 肩并肩工作得很好。限制在80个字符，这就是我的最大行长。

我曾经在 Visual Studio 工作过，在一个1920x1200的屏幕上。我会让它最大化，所有的工具窗口停靠在一边。有足够的空间留给两个并排的编辑器窗口，大约100个字符。

我还发现最长的线路来自 具有长参数列表的方法调用。这有时是一个 代码的味道: 也许方法应该是 重构。

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

我清楚地记得在什么地方读到过(我认为是在 敏捷文档中) ，为了获得最佳的可读性，一个文档的宽度应该是两个字母，或者60-70个字符。我认为旧终端的线宽部分来自于旧的排印规则。

右边距选项用于显示打印代码时页面的宽度，之前发布的文章称它被设置为80，因为从图形用户界面到穿孔卡片之前的行长都是这样的。

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

在我看来，较短的行使阅读代码和调试更容易，所以我尝试保持行的短，如果你必须设置一个限制，使自己写更好的代码，然后选择什么工作为您-也如果你是更有效率的较长的行随意增加页面大小和代码只有在广泛的屏幕上。

可怜可怜那些以后必须维护你的软件的程序员，并且坚持80个字符的限制。

喜欢80的理由:

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

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

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

• 打印不任意断行(也适用于电子邮件，网页，...)

• 将复杂性限制在一行中

• 限制缩进，从而限制方法/函数的复杂性

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

据我所知，80个字符用作编码标准，以保持与命令行编辑器的兼容性(默认终端宽度通常为80个字符)。随着现代 IDE 和大屏幕分辨率80字符可能不是“最佳”，但对于许多开发人员维护终端的可读性是必不可少的。由于这个原因，80个字符的宽度不太可能在短期内取代代码宽度的行业标准。为了回答你最后的问题，是的，代码宽度以及其他任何会影响代码可读性的特征都应该在编码标准中得到解决。

也许80个字符也是一个好点，以避免这些糟糕的获取链:

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

如果你把它限制在80个字符，也许有人会本地化这些变量并做空检查等，但也许大多数程序员会让他们在下一行。我不知道

除此之外，80个字符就像星蓝提到的那样棒。这肯定会进入编码标准。

我通常使用120-150，除非公司另有说明，但这也取决于代码的种类:

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

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

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

正如一些人在其他答案中指出的那样，80个字符限制的原因部分是历史原因(穿孔卡片、小屏幕、打印机等) ，部分是生物原因(追踪你所在的行通常不需要转头就能看到整行)。

也就是说，请记住，我们仍然是人类，我们建立工具来解决我们自己的局限性。我建议你忽略所有关于字符限制的争论，只是写一些有意义的东西，而不管它们的长度，并使用 IDE 或文本编辑器，可以帮助你正确地跟踪行。在选项卡和空格的争论中使用相同的缩进参数，以及缩进应该有多宽，我建议你使用缩进标记(最常见的是选项卡) ，让人们配置自己的 IDE 或文本编辑器来显示它们，因为他们觉得最舒服。

坚持每行有固定数量的字符，除了目标读者之外，总是会让每个人的情况变得更糟。也就是说，如果您永远不会共享代码，那么就没有理由从一开始就进行这种讨论。如果您想要共享代码，您可能应该让人们自己决定他们想要什么，而不是将您(或其他人)的理想强加给他们。

抛开硬件的限制，以及我们阅读代码与自然语言之间的差异，我认为有三个主要原因可以将行限制在80个字符左右。

1. 人类的眼球是圆的，不是真正狭窄和宽广的，和 他们的大部分分辨率都在中间。当一次阅读几个小时的时候，如果需要的话，用一个滚动条扫视眼睛会舒服得多。我不知道有什么正式的研究专门针对代码的易读性，但是根据我自己的观察，在2英尺远的显示器上，文本大小为10pt 等宽字体，100个字符占据了我水平视野的1/3，或者大约60度(在我们所有眼睛的分辨率所在的30度之外)。
2. 大多数人在工作时使用大显示器，这样他们就可以看到多个东西，而不必来回点击，这样他们就可以看到一个真正大的东西。
3. 较短的代码行包含较少的复杂性，这有望迫使开发人员将代码分解成更易于理解的单元。

这里有一项研究:

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

按照帕雷托法则，这些程序中有80% 的行小于159列。所以，为了削减低20% 和高20% ，我们有:

• 1823源代码
• 其中80% 小于159列
• 80% 都比64根柱子大

这个范围可以给你自由。你不想仅仅为了80列而限制你的代码，因为有时候你需要嵌套的循环，函数，或者一些缩进，这些在一个更大的行中很容易理解，如果你强行扭曲你的逻辑来适应任意的列宽度，你就没有使用最好的逻辑。

另一方面，有时候，一行的大小是一个指标，表明你的逻辑可以更好，你的行可以更小; 特别是如果你不是在代码的嵌套部分，你已经超过了限制，比如说，160列。

基于我自己的经验和可读性，我建议您编写代码 目标为80列，但允许直到120列的边距，永远不超过160列的限制。

此外，我们应该考虑现有的较老的阅读经验: 书。书籍的排版创建，以方便读者的眼球运动，并根据专业人士在该领域的最佳大小栏目是 理想情况下，每行约60个字符，不少于40个，不多于90个。

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

除非您正在编写低级代码，这些代码将在特定的屏幕大小和旧监视器中运行，否则我建议您遵循 地鼠标准，即 每行67个字符。

好奇心:

• 在1823年的源代码中，最大的一行是 Quine，每行有1020列
• 最大的代码行不是一个单一的行是一个文本冒险游戏与883行。当然，这是一个很好的实践，因为如果不限制换行，文本将更好地显示在屏幕上，在你实际拥有的列中进行换行。
• 最小的代码行(非零)有14个字符长。
• 我用来检查文件大小的命令是: find . -type f -name "*.c" -exec wc -L {} \; | sort -n | less -N