编程与软件工程lkml.org
不，2020 年还坚持 80 列终端已经不再“合理”
But no, 80-column terminals in 2020 isn't “reasonable” any more
2020 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 LKML 上关于代码行宽、尤其是 80 列传统是否仍然合理的邮件讨论串。争论围绕人眼阅读与代码导航、编辑器自动折行、并排 diff 以及不同语言项目的实际约束展开。
为什么经久不衰：它把“80 列是否过时”从显示器尺寸之争拉回可读性、工具和协作成本，是理解代码风格争论的经典样本。
HN 评论精选
行宽影响阅读，50–80 字符较舒适，过宽过窄都不好。
行太宽会降低可读性，因为视线从右回到左边找下一行更难。有研究称在线阅读新闻在 95 字符/行时阅读速度最快；作者个人认为正文 70 字符左右、50–80 范围较好，并觉得两端对齐更难读。
js2查看英文原文
The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl). Those that liked the 35 cpl indicated that the short line length facilitated "faster" reading and was easier because it required less eye movement. Those that liked the 95 cpl stated that they liked having more information on a page at one time. Although some participants reported that they felt like they were reading faster at 35 cpl, this condition actually resulted in the slowest reading speed. The Effects of Line Length on Reading Online News[1] 1. http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp For slabs of body copy, I like about 70 characters per line, but anything in the 50-80 range seems good. I also think justified text is harder to read, due to the lack of unique shapes to track on the right side of text — it's far easier to lose your place. https://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed I still often code on a 13" Macbook where I can open a pair of side-by-side windows in my editor with the dock on the side and get about 95 characters into each window. I typically code in Python and use a 4 space tab and a font legible to my 48 year-old eyes w/o reading glasses. On my external monitor, I take advantage of the extra width to open additional windows. So I dunno, still prefer 80-88 characters for coding, 100 max. The grep thing seems like a red-herring. Use grep's -A, -B, and -C options to get more context.
最佳行宽受视觉生理限制，不会随屏幕变大而无限增加。
最佳代码行宽和显示器或窗口宽度关系很小，更主要是人眼分辨率和视野的生理限制。10 米宽显示器近距离也看不全；离远就得放大字体，每行字符数不会变多少。手机和桌面屏的角尺寸相近，换大屏并不会让长行自动合适；从长行代码切到 80 列真是解脱。
avodonosov查看英文原文
Optimal code line width has very little to do with monitor or window width. It's more of an anatomical restriction: the resolution of the human eye and the field of view. For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters per line we can use doesn't change much. Not so long ago I showed a piece of code on a mobile phone to a colleague, saying he should use shorter lines. He replied I need a larger display. When I opened the same code on my desktop display the lines were not fitting the editor window almost the same as on the mobile screen. (The angular sizes of a mobile phone screen and individual characters on it are approximately the same as of the bigger screen and characters on it because we keep phone closer to eyes). I currently work with a codebase where long lines are used and it is so inconvenient. When I switch to some 80-cols code it is such a relief.
80 列不是硬件限制，而是视觉和代码导航的需要。
Linus 在做一个常见的恶意论证：人们用 80 列是因为硬件限制。从来没有人因为硬件限制提倡 80 列；硬件进步了，但我们的眼睛没变。散文短行便于换行；编程短行让你更容易在较小区域内跟踪函数，长行需要更多眼动。短行还会迫使调用函数时一行一个参数；没人要求你把变量名缩短。
xdennis查看英文原文
Linus is making the typical bad faith argument that people use 80 char limit because of hardware limitations. No one has ever advocated 80 because of hardware limits. Hardware has progressed but our eyes haven't. In prose, shorter lines help because you can easily go to the next line. For programming, shorter lines help because you can navigate your function better because most of what you're tracking is in a smaller area. With long lines you have to move your eyes more. Shorter lines also force you to write one param per line when calling a function. No one is saying you need to mk yr vrbls shorter.
并排 diff 让 80 列实际需要更宽窗口，不能假设人人有大屏。
我常遇到的问题不是编辑器读代码时折行，而是看 side-by-side diff（如 GitHub PR 或 Review Board）时折行。你不仅要双倍代码宽度，还要每侧约 6 列行号、边距和滚动条；所以不想折行时，80 列文本实际需要约 180 列窗口。普通开发笔记本上全屏终端默认 11pt 是 202 列，调到 13pt 降到 176 列，就无法无折行查看双 80 列的 PR diff。要求每个人有大屏幕或好视力会排除很多人。
evilotto查看英文原文
The main problem I often run into is not wrapping when reading code in an editor, but rather wrapping when reading side-by-side diffs, for example in a github PR or review board RB. You get not only double the code width, but also an extra 6 or so columns on each side for line numbers, plus margins and scrollbars; so 80-column text is really more like 180 columns wide that your window needs to be if you don't want any wrapping. On my typical developer laptop a full-screen terminal window (which I personally never use) with a system default 11pt font is 202 columns. A modest bump to 13pt drops that to 176 columns, meaning I can't view a side-by-side 80-column wide PR diff without some line wrapping. That's great that you have a 350-character wide display. Requiring everyone to have acres of screen space, either because they can afford a 34" monitor (or 2 24" monitors) OR because they have good enough eyesight to be able to use a microscopic font is excluding a lot of people.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选