代码的最佳行长度

参考：https://en.wikipedia.org/wiki/Chinese_numerology#Eight

好啦好啦，显然这事没这么简单。关于代码行长度的争论由来已久，热度堪比“用制表符还是空格缩进”的世纪之争。就连向来立场鲜明的Black，其实也支持用户自定义行长度

参考：https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#labels-line-length）

过往由来

有些观点有趣的人总爱说：“都21世纪20年代了，为啥还要按80个字符换行，搞得跟用老式电传打字机teletypes（早期计算机输入输出硬件）似的？我都用超宽屏显示器了！”

他们的言外之意是，80字符的终端terminal（计算机交互界面）宽度是过时的产物，完全源于早年的硬件限制；而现代显示器能容纳大篇幅单行内容，就该把这个硬件能力用满。

从古今硬件的巨大差距来看，这话听着确实有道理：我自己的显示器，单行轻松能放下约350个字符，这么大的空间空着不用，实在太可惜了。

但事实真的如此吗？

我曾把编辑器窗口拉到最宽测出了350这个数字，却不会一直用这个宽度写代码。为了获得更舒适的编辑体验，我会切回专注写作模式writeroom mode（https://github.com/joostkremers/writeroom-mode）一种限制行宽、减少视觉干扰的编辑模式）——无论窗口多大，这个模式都会把单行长度限定在92个字符。

你大概率也发现过一个现象：几乎所有展示纯文本的网站，即便在超宽屏上，也会限制文本的显示宽度。

把新闻网站或博客全屏后，屏幕中间那一小列文字看着或许很别扭，但如果一个网站不做宽度限制，全屏后文字占满整个屏幕，阅读体验会变得极差，几乎难以辨认（参考：https://danluu.com/）

博客工具给文本设置列宽限制，绝非因为早年80字符终端的历史巧合。

同理，若写代码时非要把超宽屏的空间用满，让单行代码达到200-300个字符，你很快会觉得别扭又混乱，也极易找不到代码位置。“80字符只是老旧技术的产物，把超宽屏的像素都用起来”这种说法，嘴上说起来很讨喜，但实际使用中，大家顶多只是想要多一点字符空间，行宽上限一般也就100个字符，远比超宽屏能容纳的宽度窄得多。

这么看，80字符的终端限制或许确实有点束缚，但等等——早年的终端为何偏偏设定为80个字符宽度？

溯源根由

正如软件工程栈交换网Software Engineering Stack Exchange（https://softwareengineering.stackexchange.com/a/148729）的一篇优质帖子总结的：终端的80字符宽度源于电传打字机，电传打字机的80字符宽度源于穿孔卡片punch cards（早期计算机的存储与输入介质），而穿孔卡片的80字符宽度，本质是因为这个长度刚好适配美式信纸US-Letter上一行能打印的字符数。

甚至在打字机出现前，我们看看普通报纸就懂了：为啥报纸上固定的特色文章板块叫“专栏”？因为大幅报纸的版面太宽，根本无法单栏排版，必须拆分成多个专栏——报纸专栏的单行字符数通常只有30个，比80字符的限制严苛得多。

初代报纸印刷机是定制设计的，本可以随意设定版面宽度，那为何要标准化成如此窄的专栏呢？

科学依据

关于文本行宽的问题，已有不少相关的科学研究（参考：https://en.wikipedia.org/wiki/Line_length），简单来说，这背后有人类的生理原因：阅读文本时，眼睛并非像拖动鼠标光标那样，逐字缓慢移动，而是以快速跳动的方式移动，这种运动被称为眼跳运动saccades（https://en.wikipedia.org/wiki/Saccade）。

想要快速、准确地从一行文本跳转到下一行，下一行的开头必须能出现在读者的周边视野中，这样才能精准定位。这就限制了读者单次眼跳的转动角度，也因此限定了舒适阅读的文本行宽——如果行宽过长，读者读到行尾时，总要费力寻找下一行开头。

如此看来，把行宽限制在80（或88）个字符，其实并不算离谱，毕竟比报纸专栏的30字符要宽得多。

但这事若只有这一层原因，最初也不会引发这么大的争议，对吧？

注意要点

显示器确实变宽了

那些推崇超宽屏的人，其实也有一定道理，只是他们最初对“老旧终端”的理解过于片面。现代的超宽屏显示器，对于文本展示的利用率确实低得可惜。

即便编辑器左侧加上占空间的文件、类、方法导航树，右侧加上代码预览窗格，在谷歌图片搜索“VS Code”也能发现，大部分打开的编辑器窗口右侧，都有大片的空白区域。

大屏显示器的实用性很强：我们可以利用空间记忆，把更多相关代码展现在屏幕上，思考时只需扫一眼就能看到，无需频繁切换页面。但这一优势的发挥，需要我们主动去利用。

报纸通过密集的多栏排版（最多可达6栏），让读者无需频繁翻页，就能一次性阅读大量信息；读者可以读完一栏到页底，再回到顶部读下一栏，反复如此。

书籍也是同理，左右两页都印满文字，让读者翻页前能阅读的内容翻倍。

你或许会发现，在实体书或电子书应用里读文本，比在浏览器里翻页读大量文本更舒适——原因就在于人类的眼睛天生适应眼跳运动；而在浏览器中，需要反复跟随滚动的页面直到停下，再重新定位新的阅读起点，这个过程会实实在在地加重眼部肌肉的负担。

抄本codex（https://en.wikipedia.org/wiki/Codex，区别于卷轴的典籍形式，是现代书籍的雏形）能取代卷轴成为重大的技术革新，原因也正在于此。而如今浏览器的滚动式阅读，其实是一种倒退。

在当下，合理的做法是：在文本编辑器或集成开发环境IDE（Integrated Development Environment，整合代码编辑、编译、调试功能的工具）中使用水平拆分窗格panes，并且主动为当前解决的问题，在屏幕上排布好相关的代码。

不过，这一领域也成了不同IDE打造差异化的突破口——开发出支持多栏连续阅读代码的布局，让代码缓冲区可以自动换行，还能像读报纸一样导航。

此外，现代层叠样式表CSS（https://developer.mozilla.org/en-US/docs/Web/CSS/columns）对多栏布局的支持已经非常完善，可惜真正的多栏、翻页式布局却十分少见。

如果我能找到一种方式，在不显得生硬、也不违背“横向滚动比纵向滚动更麻烦且体验不一致”这类现代平台惯例的前提下实现多栏布局，或许会在我的博客上做一次尝试。在那之前……恐怕只能把浏览器窗口调窄，让屏幕的其他区域能放下一些有用的内容了。

代码并非纯文本

不过，我有点跑题了。虽然我认为多栏布局读纯文本是个值得更多人尝试的有趣方式，但代码和纯文本终究不同。

如果你点开过前面的维基百科链接，应该会发现，衡量理想行宽的指标并非“编辑器窗口中的字符格数”，而是字符/行CPL（characters per line），即单行的字符数量。

人类舒适阅读的CPL范围在45-95之间，而代码的行宽设定在90个字符左右，其实是最优解——因为空格会占用行宽的“预算”。

在一个典型的面向对象Python程序中，大部分代码的缩进至少有8个空格：类作用域缩进4个，方法作用域再缩进4个；更复杂的代码缩进甚至会达到12个，因为任何有实际逻辑的代码，至少会包含一个条件判断或循环。

如此一来，90个字符的行宽上限，实际可用的字符数大概只有78个——这个数字，恰好和我们最初提到的、适配美式信纸的打字机单行字符数完美契合。

软换行又该怎么看？

理论上，源代码是结构化的信息，其展示形式可以与序列化的存储形式完全分离。每个人都可以根据自己的喜好、自身的眼部生理特点，配置心仪的行宽；代码则可以按照对应编程语言的规则格式化，而“硬换行”也会成为过时的做法。

这里的软换行soft-wrap，指编辑器自动为长行代码换行，不会修改代码本身的字符结构；硬换行hard wrapping，指手动在代码中添加换行符，改变代码的序列化存储形式。

最优行宽究竟该设为多少？

说到底，这个具体数值最终还是因人而异的个人选择。 希望通过了解行宽设定背后的发展历程、科学依据以及底层物理限制，你能结合自身使用场景选出适配的数值，让其在阅读体验、与技术栈中相关工具的兼容性、代码差异对比篇幅、协作人员常用编辑器和集成开发环境的显示效果，以及在网页、演示幻灯片等场景下的正常展示等方面达成平衡。 但有一点至关重要，在此要提出相反观点： 其实根本没必要自己挑选最优行宽，因为这个答案早已为你确定 —— 就是 88

#代码行长度 #88字符 #眼跳运动 #CPL #超宽屏 #编辑器布局 #软换行 #代码缩进