如果您在所选的 IDE 中启用了“查看右边距”，那么默认情况下它可能是80个字符。我倾向于将其更改为120，没有其他公司要求我以不同的方式操作，只因为几年前我在一家公司的标准就是这样。我的问题是，是否有任何研究实际上显示80个字符是代码可读性的最佳最大宽度，还是这个值只是“一直以来就是这样”，没有人真正知道为什么是这样的？此外，代码行的宽度是否应该成为您的编码规范的一部分？
最佳代码宽度的研究？
182
- Fostah
8
1虽然我不知道有没有相关的研究，但你会发现很多人对这个问题有自己的看法：* 在当今这个时代，强制限制代码文件的最大宽度为80个字符是否有合理的理由？ - Adam Bellaire
3据我所知，没有相关研究，但你可能会发现查看不同项目的编码标准很有趣。例如，谷歌的标准是80个字符。（http://code.google.com/p/google-styleguide/），而WebKit（苹果的？）据我所知没有限制（http://www.webkit.org/coding/coding-style.html）。Mozilla的标准似乎是80（https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide#Line_length）。 - gman
也许相关（针对散文）：https://en.wikipedia.org/wiki/Line_length - Emile Cormier
一个由工具强制执行的良好格式化风格可以在这里帮助很多。 - Thorbjørn Ravn Andersen
1我想这个帖子被关闭是件好事，不是因为给出的虚假理由，而是因为这些“答案”并没有回答问题，只是一些自圆其说的理由，通常非常愚蠢，比如“我认为在书籍中适用于最佳行长的一般原则同样适用于阅读代码。也就是说，较窄的列可以更快地阅读，而较宽的列则需要更长时间。”-- 尽可能快速地阅读代码并不是一个目标。 - Jim Balter
显示剩余3条评论
11个回答
159
请为那些日后需要维护你软件的程序员着想，将每行代码限制在80个字符以内。
选择80个字符的原因是：
可在笔记本电脑上使用更大字体进行阅读
留出空间便于将两个版本并排比较
留出空间用于IDE中的导航视图
不会任意断行地打印（同样适用于电子邮件、网页等）
限制一行代码的复杂性
限制缩进，从而限制方法/函数的复杂性
这应该是编码规范的一部分。
- starblue
13
16将代码行宽保持在80个字符或更少是个好主意，原因很多。我对你的回答印象深刻，觉得很正确，但很惊讶（失望）它没能得到更多的积分。除此清单外，我还想补充：（1）横向滚动很烦人。（2）通过在多列中查看代码，可以大大增加你正在处理的代码的密度。当有一些行远超其他行时，大量的空间就被浪费了。 - Donnie Cameron
6好的，但如果一段代码缺少缩进怎么办？这种情况发生在我身上过，80个字符并不好处理。 - EKanadily
37限制一行内的复杂度。我不确定为什么将复杂性分散到多行中会更好。这只会在你的大脑中增加更多负担。 - Jonathan
11这是一个非常老的话题了。但现在你是否仍然认同很多开发人员使用27英寸的显示器 :-）。我的意思是，如果视力有问题，更大的屏幕可能会有所帮助。8年前，我们还在使用17或20英寸的显示器，甚至有些人使用4：3的分辨率。 - Mathijs Segers
7将代码变窄意味着它变得更长，一次性可见的内容也会减少，因此在我看来实际上更难阅读。 - Tuntable
显示剩余8条评论
140
实际上，80列这个概念早在DOS之前就存在了。它来源于卡片打孔机，这是一种80列设备。
为了回答原帖的问题，有一个“研究”已经进行了大约600年——印刷书籍。随着时间的推移，这些书籍考虑到易读性而不断发展，现在文本的平均行长度约为60个字符。因此，为了易读性，应该选择较窄的页边距。
为了回答原帖的问题，有一个“研究”已经进行了大约600年——印刷书籍。随着时间的推移，这些书籍考虑到易读性而不断发展，现在文本的平均行长度约为60个字符。因此，为了易读性，应该选择较窄的页边距。
- anon
11
127就可用性而言，我并不认为您可以将阅读自然语言与阅读编程语言进行比较。 - Frug
35@Frug - 实际上，你可能可以。限制每行字符数为65并不是因为较大的行无法阅读，而是当眼睛移动到下一行时弧度太紧。您可以通过增加行高来解决此问题，但这会使块间距更难以用于传达含义，因此在IDE中可能要避免使用。 - Jimmy Breck-McKye
43@Jim - 我的母语中没有30个字符的单词（也不会使用），并且语法与编程语言完全不同。通常可以将一行代码分组，无论是长条件语句还是长方法和类的组合。再加上缩进，两种语言之间的比较变得荒谬了。我毫不怀疑，任何科学研究可读性和行长度的人都会反对你淡化这些差异。 - Frug
13@Frug - 我没看出你的反对如何与我所提出的任何论点相关，但我可以看出缩进会破坏我所提出的模型。不过请不要称呼我为“Jim”。 - Jimmy Breck-McKye
25如果读者想要不用扭曲脖子就能阅读书籍，通常需要将书放得更靠近眼睛，这意味着每行文字所容纳的字符数量更少。相比之下，屏幕一般不会与书本距离相同，因此可以使用更多字符数，同时仍保持在最大视角限制内。此外，代码通常不是阅读而是浏览，因此宽度不那么重要。在我的笔记本电脑屏幕上，我（可能因人而异）可以轻松阅读120个字符的代码行，但在我的15英寸笔记本电脑上，两个emacs缓冲区这个宽度太宽了。 - fcar
显示剩余6条评论
51
我没有学过相关专业，但我会分享一下我的经验。
我发现在处理文本时水平滚动很繁琐。 我会考虑代码将要使用的环境，并基于该上下文设置宽度标准。
例如，当我在XWindows上使用Emacs时，始终保持两个Emacs窗口并排效果很好。 这将它们限制为80个字符，因此这是我的最大行长度。
曾经我在1920x1200的屏幕上使用Visual Studio。 我会将其最大化，并将所有工具窗口都停靠在一侧。 剩余的空间足够放置两个编辑器窗口并排，每个窗口大约100个字符。
我还发现，最长的行来自于拥有长参数列表的方法调用。这有时是一个代码异味：也许应该重构该方法。
如果您和您的合作者拥有高分辨率屏幕和清晰的视力，请使用小字体和长行。反之，则需要使用短行。
- Jay Bazuzi
2
1加一分给“鹰眼”因为这确实是我遇到的情况。 - EKanadily
应该容忍水平滚动的例外情况是针对常量数据表，以避免行跨越多行。 - Emile Cormier
39
我通常使用120-150的行宽，除非公司有不同的要求。然而，这也取决于代码的种类：
- 我(几乎)从不在一行上使用多个语句。
- 只有当类似的行可以对齐并且不被打断时，我才使用长行(>12)。
- 我总是使用足够的空格/括号等。
- 我喜欢较长的变量名而不是短的。
几年前我限制在100之内，但现在宽屏幕通常得到应用和高分辨率显示器，甚至可以在笔记本电脑上看到120(我几乎不使用笔记本电脑)。
将屏幕与书进行比较并不是一个很好的方法，因为书有更多的垂直空间，而屏幕有更多的水平空间。我总是尝试使一个函数最多在一个可见的屏幕长度内。
- Michel Keijzers
9
7在多个窗口并排打开时，每行120-150个字符的工作原理是怎样的？您是否会同时打开多个代码编辑器窗口？在我的30英寸显示器上，如果我将每行字符限制在97个字符/行，则可以同时打开3个窗口。 - KajMagnus
3我使用大屏幕编程，也喜欢更多的代码显示在屏幕上。我的目标是将每行代码保持在110-130个字符之间，因为我认为这样可以提高可读性。有时，将语句分成2-3行反而会降低可读性。有些时候，我会将每行代码增加到500-1000个字符，以便隐藏掉一些不需要看到的内容，比如注释、禁用的代码和某些硬编码的值。我认为这取决于程序员自己。如果大多数程序员将每行代码限制在80个字符以内，那么在处理共享代码时最好也遵循这个规则。 - SunsetQuest
120-150个字符长度的行使得无法显示三方合并窗口，而这是在团队成员之间进行大量代码更改且彼此重叠时最有效的合并方式（这是大多数团队的情况）。这种超宽行可以软换行，但这样做非常丑陋且难以阅读。 - sola
谢谢你解释，@sola。我为你感到遗憾，并且我记得在较大的团队中（例如，多达17个人）需要进行更多的合并，但我仍然想知道是否可以通过更好地管理工作（更好地划分程序员之间的工作范围）来减少这个问题。当你花费50%的时间来合并提交时，你就知道你离热死亡很近了。 - undefined
谢谢你解释，@sola。我为你感到抱歉。我记得团队规模增加了（比如增加到17人），但我仍然怀疑更好的工作管理（程序员之间的划分）是否能减少这种情况。当你花费50%的时间来合并提交时，你就知道你接近热死亡了。但回到最初的问题——这只是再次确认这并不是为了证明更短的行长度而存在的理由。我记不起上次进行三方合并是什么时候了，我应该为了这种情况来优化整个代码库吗？ - undefined
显示剩余4条评论
11
除了硬件限制和阅读代码与自然语言的方式不同之外，我认为将行数限制在80个字符左右有三个主要原因。
- 人眼是圆形的，而不是非常狭窄和宽阔的，大部分视觉分辨率集中在中央区域。长时间阅读时，使用一个滚动条需要在短弧线上移动眼睛更加舒适。我不知道是否有正式的针对代码易读性的研究，但从我自己的观察来看，在距离显示器两英尺处，文本使用10pt等宽字体大小，100个字符占据了水平视野的约1/3，或者大约60度 (超出所有眼睛分辨率都在的30度左右的范围)。
- 大多数人在工作中使用大型显示器，以便可以同时看到多个东西而无需来回点击，而不是为了看到一个特别大的东西。
- 较短的行包含较少的复杂度，这会带来良好的影响，强制开发人员将其代码分解成更易于理解的单元。
- maurice
1
1我同意“无需点击即可查看多个内容”的观点。我们与飞行员在驾驶舱中需要可视化大量数据的需求相同。集成开发环境并不一定理解这一点，浪费了很多像素。 - Thorbjørn Ravn Andersen
9
也许80个字符也是避免这些糟糕的getter链的一个好点：
object.getFoo().getBar().getFooBar().get ...
如果您将它限制在80个字符内，也许有人会对这些变量进行本地化和null检查等处理，但大多数程序员可能会让它们换行。我不知道。
除此之外，正如starblue所提到的，80个字符是很好的。这一点应该绝对纳入编码标准中。
- Christopher Klewes
1
10FYI，过度的方法链式调用被称为“火车失事反模式（train wreck anti-pattern）”（参考链接：http://c2.com/cgi/wiki?TrainWreck）。 - Dennis
8
这里有一项研究：
我教授编程超过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个字符的quine程序
- 不是单行的最长代码行是一个文本冒险游戏，共883行。当然，这是一个好的实践，因为如果你不限制换行，文本会更好地显示在屏幕上，并在实际列宽处自动换行。
- 最小的代码行（非零）长度为14个字符。
- 我用的命令来检查文件大小是：
find . -type f -name "*.c" -exec wc -L {} \; | sort -n | less -N
- DrBeco
9
1这些源代码是学生作业吗？它们可能不反映出生产质量的代码 - 根据我的经验，完整的错误处理会增加很多额外的缩进语句。 - Thorbjørn Ravn Andersen
回答你的问题：是的，它们是学生作业。 - DrBeco
1这可能真的很有趣 - 程序员成熟后，代码会如何改变。 - Thorbjørn Ravn Andersen
是的...从这样的数据库中学习会非常好。我想问题在于收集这样的数据。 - DrBeco
学习@ThorbjørnRavnAndersen的另一个问题是，仅仅因为你在企业环境中找到了这段代码并投入生产，并不意味着它是成熟的；-) - undefined
显示剩余4条评论
4
我清楚地记得在某个地方读到过（我想是在敏捷文档中），为了最佳可读性，文档的宽度应该大约是两个字母表，即60-70个字符。我认为旧终端的行宽部分来自于这个古老的印刷规则。
- lindelof
1
不，它没有：https://www.ibm.com/ibm/history/ibm100/us/en/icons/punchcard/ ... 而且也没有所谓的 "排版规则"，基于字母表大小的规则毫无意义（哦，可怜的中国人）。说你记得在某个地方读到过某个东西完全没用。即使你确实在某处读到了，那又怎样？没理由认为你的信息源是正确/有效/权威的... 它很可能是由一些人写成的，这些人将他们的观点作为回答请求研究的答案发布在这里... 这些论文应该是基于事实、证据之类的东西。 - Jim Balter
4
右边距选项是为了在打印代码时显示页面的宽度。如先前所述，之所以将其设置为80，是因为在 GUI 出现之前，从穿孔卡片开始历史上行长度就是80。
最近我在某个博客上看到了一个建议（记不清是哪个博客了），建议增加 IDE 字体大小以改善代码质量。其逻辑是，如果屏幕上放不下太多代码，则您将编写更短的行和函数。
我认为较短的行使代码阅读和调试更容易，因此我试图保持行尽可能短。如果您必须设置限制以编写更好的代码，则应选择适合自己的限制。另外，如果您使用较长的行更有效率，则可以随意增大页面大小，在宽屏上编写代码。
最近我在某个博客上看到了一个建议（记不清是哪个博客了），建议增加 IDE 字体大小以改善代码质量。其逻辑是，如果屏幕上放不下太多代码，则您将编写更短的行和函数。
我认为较短的行使代码阅读和调试更容易，因此我试图保持行尽可能短。如果您必须设置限制以编写更好的代码，则应选择适合自己的限制。另外，如果您使用较长的行更有效率，则可以随意增大页面大小，在宽屏上编写代码。
- Nir
2
能够打印代码几乎是一门被遗忘的艺术。使用荧光笔并在边缘进行注释是理解的重要工具。 - Thorbjørn Ravn Andersen
这个问题是关于学习的，但在这些答案中我们得到的都是个人意见。 - Jim Balter
2
一些人在其他答案中指出，80个字符限制的原因部分是历史性的（打孔卡、小屏幕、打印机等），部分是生物学的（为了跟踪你所在的行，通常最好能够看到整行而不需要转头）。
尽管如此，请记住我们仍然是人类，我们构建工具来解决自己的限制。我建议您忽略有关字符限制的整个辩论，只需编写有意义的内容，而不考虑其长度，并使用可以帮助您正确跟踪行的IDE或文本编辑器。针对制表符与空格之争中缩进应该有多宽的相同论点，我建议您使用缩进标记（最常见的是制表符），并让人们配置自己的IDE或文本编辑器以按照他们最舒适的方式显示它们。
坚持每行固定字符数将始终使事情变得更糟，除了针对目标受众。尽管如此，如果您永远不会共享代码，那么根本没有理由开始这个讨论。如果您想分享代码，您应该让人们自行决定他们想要什么，而不是强加您（或其他人）的理想。
尽管如此，请记住我们仍然是人类，我们构建工具来解决自己的限制。我建议您忽略有关字符限制的整个辩论，只需编写有意义的内容，而不考虑其长度，并使用可以帮助您正确跟踪行的IDE或文本编辑器。针对制表符与空格之争中缩进应该有多宽的相同论点，我建议您使用缩进标记（最常见的是制表符），并让人们配置自己的IDE或文本编辑器以按照他们最舒适的方式显示它们。
坚持每行固定字符数将始终使事情变得更糟，除了针对目标受众。尽管如此，如果您永远不会共享代码，那么根本没有理由开始这个讨论。如果您想分享代码，您应该让人们自行决定他们想要什么，而不是强加您（或其他人）的理想。
- Jonas Lihnell
1
这是完全的历史：https://www.ibm.com/ibm/history/ibm100/us/en/icons/punchcard/ - Jim Balter
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接