Actually, the 80-column thing long precedes DOS. It comes from card punches, which were 80-column devices.
And to kind of answer the OP's question, one "study" has been going on for about 600 years now - the printed book. These have evolved over the centuries, with readbility foremost in mind, to the position we are at now where the average line length for text is around 60 characters. So for readability, go for narrower margins.
I don't have studies, but I will relate my experience.
I find that horizontal scrolling is tedious when dealing with text. I look at the environment that the code will be used in, and set width standards based on that context.
For example, when I worked in Emacs on XWindows, it worked well to have 2 Emacs windows side-by-side at all times. That limited them to 80 characters, so that was my max line length.
At one point I worked in Visual Studio on a 1920x1200 screen. I'd keep it maximized, with all tool windows docked down one side. There was enough space left for two editor windows side-by-side at around 100 characters.
I also find that the longest lines come from method calls with long parameter lists. This is sometimes a code smell: perhaps the method should be refactored.
If you & your co-programmers have high-resolution screens and sharp eyesight, by all means use a small font and long lines. Conversely, you may need short lines.
I normally use 120-150 unless the company describes otherwise. However it depends also on the kind of code:
I (almost) never use multiple statements on one line
I only use long lines (>12) only if lines that look similar can be aligned and not broken.
I always use enough spaces/parenthesis etc
I prefer longer variables names above shorter names
Until a few years ago I limited to 100 but now widescreens are normally used and high resolution monitors 120 can be even seen on laptops (which I barely use).
Comparing a screen to a book is not really good because a book has more vertical space and a screen has more horizontal space. I always try to keep a function max. one visible screen long.
I teach programming for more than 30 years, and during this time I accumulated 1823 source codes in C with various routines, from random small games to neural networks, compilers, educational softwares, automatically generated lex/yacc source codes, etc.
Following the Pareto Principle, 80% of those programs have lines smaller than 159 columns. So, to cut the lower 20% and the upper 20%, we have:
1823 source codes
80% of them smaller than 159 columns
80% of them bigger than 64 columns
Now that is a range that gives you freedom. You don't want to limit your code to 80 columns just for the sake of it, because sometimes you will need nested loops, functions, or some indentation that will be easy to understand in a bigger line, and if you forcibly distort your logic to fit an arbitrary column width, you are not using the best logic.
Sometimes, on the other hand, the size of a line is an indicator that your logic could be better, and your line could be smaller; specially if you are not in a nested part of the code and you already crossed the limit of, say, 160 columns.
Based on my own experience and readability, I recommend you write your code aiming for 80 columns, but allowing until 120 columns of margin, and never crossing the 160 columns limit.
Also, we should consider the older experience of reading that exists: books. Books are typographically created to easy the reader's eye movement, and the best sized column according to professionals in the area is ideally around 60 characters per line, not less than 40, not more than 90.
Since coding is not exactly reading a book we can go for the upper limit, and we should stay between 80 and 90 characters per line.
Unless you are programming low level code that will run in specific screen sizes and old monitors, than I would recommend you follow gopher standard, which is 67 characters per line.
Curiosity:
the biggest line in the 1823 source codes is a quine of 1020 columns in a single line
the biggest line of code that is not a single line is a text adventure game with 883 lines. Of course this is good practice, because if you don't limit the break of a line, the text will be better displayed in your screen, breaking in the column you actually have as size.
the smallest lines of code (non zero) are 14 characters long.
the command I used to check the file sizes is: find . -type f -name "*.c" -exec wc -L {} \; | sort -n | less -N
Disregarding hardware restrictions, and any differences in how we read code versus natural language, I see three primary reasons to limit lines to around 80 characters.
Human eyeballs are round, not really narrow and wide, and most of their resolution is in the middle. When reading for hours at a time it is a lot more comfortable to sweep the eyes in short arcs, using one scroll bar as needed. I don't know of a formal study specific to the legibility of code, but from my own observations, with the monitor 2 feet away, with text sized at a 10pt monospaced font, 100 characters takes up about 1/3 of my horizontal field of vision, or around 60 degrees (outside of the 30 degrees or so where all our eyes' resolution is at).
Most people use a large monitor at work so that they can see multiple things without clicking back and forth, not so that they can see one thing really big.
Shorter lines contain less complexity, which hopefully forces a developer to break up make their code into more digestible units.
Maybe the 80 characters is also a good point to avoid these bad getter chains:
object.getFoo().getBar().getFooBar().get ...
if you limit it to 80 characters, maybe someone would localize these variables and do null check etc, but maybe most programmers would let them wrap in the next row. i don't know
Beside that, 80 characters are great as starblue mentioned. This should defenitely goes into the coding standards.
I distinctly remember reading somewhere (I think it was in Agile Documentation) that for optimal readability a document's width should be about two alphabets, or 60-70 characters. I think the old terminals' line width came in part from that old typographical rule.
The right margin option is intended to show you the width of the page if you're going to print the code, and has previous posted said it was set to 80 because that's what the line length historically was before GUI all the way back to punch cards.
I've seen a recommendation on some blog recently (can't remember what blog) to increase you IDE font size in order to improve code quality, the logic behind it is that if less code fits on screen you'll write shorter lines and shouter functions.
In my opinion shorter lines make reading the code and debugging it easier, so I try to keep the lines short, if you have to set a limit to make yourself write better code then choose what works for you - also if you are more productive with longer lines feel free to increase the page size and code only on a wide screens.
也就是说，请记住，我们仍然是人类，我们构建工具来解决我们自身的局限性。 我建议您忽略有关字符限制的整个争论，只编写有意义的内容，无论其长度如何，并使用可以帮助您正确跟踪行的 IDE 或文本编辑器。 在制表符与空格的争论中使用相同的缩进参数，以及缩进应该有多宽，我建议您使用缩进标记（最常见的是制表符），然后让人们配置自己的 IDE 或文本编辑器来显示它们因为他们觉得最舒服。
As some people have pointed out in other answers the reason for the 80 character limit is partly historical (punch cards, small screens, printers etc) and partly biological (to track what line you are in it's generally good to be able to see the entire line without needing to turn the head).
That said, please remember that we are still humans and we build tools to solve our own limitations. I propose you ignore the entire debate about character limitation and just write stuff that makes sense regardless of their length, and use an IDE or text editor that can help you keep track of the lines properly. Using the same argument for indentation in the tabs vs spaces debate, as well as the how wide should the indentations be I propose you use an indentation marker (most commonly the tab) and just have people configure their own IDE or text editors to display them as they find most comfortable to them.
Sticking with a fixed number of characters per line will always make things worse for everyone but the targeted audience. That said, if you will never share the code, ever; then there's really no reason to even have this discussion to begin with. Should you want to share the code, you should probably let people decide what they want on their own instead of forcing yours (or someone elses) ideals on them.
To the best of my knowledge the 80 character is used as a coding standard to maintain compatibility with command line editors (default terminal width is typically 80 characters). With modern IDEs and large screen resolutions 80 characters is probably not "optimal", but for many developers maintaining readability in the terminal is essential. For that reason it is not likely that 80 character width will be replaced as the de facto standard for code width anytime soon. And to answer your final question, yes, code width as well as any other characteristic which will affect your code's readability should be addressed in your coding standards.
发布评论
评论（11）
实际上，80 列的东西远远早于 DOS 。 它来自打卡机，这是 80 列的设备。
为了回答OP的问题，一项“研究”已经进行了大约600年——印刷书。 这些已经发展了几个世纪，以可读性为首要考虑，到了我们现在的位置，文本的平均行长度约为 60 个字符。 因此，为了提高可读性，请选择较窄的页边距。
Actually, the 80-column thing long precedes DOS. It comes from card punches, which were 80-column devices.
And to kind of answer the OP's question, one "study" has been going on for about 600 years now - the printed book. These have evolved over the centuries, with readbility foremost in mind, to the position we are at now where the average line length for text is around 60 characters. So for readability, go for narrower margins.
我没有学过，但我会讲述我的经历。
我发现处理文本时水平滚动很乏味。 我查看代码将使用的环境，并根据该上下文设置宽度标准。
例如，当我在 XWindows 上使用 Emacs 时，始终并排有 2 个 Emacs 窗口效果很好。 这将它们限制为 80 个字符，所以这是我的最大行长度。
有一次，我在 Visual Studio 中的 1920x1200 屏幕上工作。 我会将其保持最大化，所有工具窗口都停靠在一侧。 剩下的空间足以容纳两个并排的编辑器窗口（大约 100 个字符）。
我还发现最长的行来自具有长参数列表的方法调用。 有时，这是一种代码异味：也许该方法应该重构。
如果你& 你的合作程序员拥有高分辨率的屏幕和敏锐的视力，一定要使用小字体和长线条。 相反，您可能需要短线。
I don't have studies, but I will relate my experience.
I find that horizontal scrolling is tedious when dealing with text. I look at the environment that the code will be used in, and set width standards based on that context.
For example, when I worked in Emacs on XWindows, it worked well to have 2 Emacs windows side-by-side at all times. That limited them to 80 characters, so that was my max line length.
At one point I worked in Visual Studio on a 1920x1200 screen. I'd keep it maximized, with all tool windows docked down one side. There was enough space left for two editor windows side-by-side at around 100 characters.
I also find that the longest lines come from method calls with long parameter lists. This is sometimes a code smell: perhaps the method should be refactored.
If you & your co-programmers have high-resolution screens and sharp eyesight, by all means use a small font and long lines. Conversely, you may need short lines.
除非公司另有说明，我通常使用 120-150。 然而，这也取决于代码的类型：
直到几年前，我限制为 100，但现在通常使用宽屏，甚至可以在笔记本电脑上看到 120 的高分辨率显示器（我几乎不使用）。
将屏幕与书籍进行比较并不是很好，因为书籍有更多的垂直空间，而屏幕有更多的水平空间。 我总是尝试保持函数最大值。 一个可见屏幕长。
I normally use 120-150 unless the company describes otherwise. However it depends also on the kind of code:
Until a few years ago I limited to 100 but now widescreens are normally used and high resolution monitors 120 can be even seen on laptops (which I barely use).
Comparing a screen to a book is not really good because a book has more vertical space and a screen has more horizontal space. I always try to keep a function max. one visible screen long.
这是给你的一个研究：
我教编程超过30年，在这段时间里我积累了1823个C源代码，其中包含各种例程，从随机小游戏到神经网络、编译器、教育软件、自动生成的lex/yacc源 遵循帕累托原则
，80% 的程序的行数小于 159 列。 因此，为了削减较低的 20% 和较高的 20%，我们有：
现在这是一个给你自由的范围。 您不想仅仅为了代码而将代码限制为 80 列，因为有时您需要嵌套循环、函数或一些缩进，这些缩进在更大的行中很容易理解，并且如果您强行扭曲您的逻辑为了适应任意列宽，您没有使用最佳逻辑。
另一方面，有时候，线条的大小表明你的逻辑可以更好，并且你的线条可以更小； 特别是如果您不在代码的嵌套部分并且您已经超过了 160 列的限制。
根据我自己的经验和可读性，我建议您编写代码瞄准 80 列，但允许 120 列的边距，并且永远不要超过 160 列的限制。
此外，我们应该考虑旧的经验现有的阅读内容：书籍。 排版设计是为了方便读者的眼球移动，根据该领域的专业人士的说法，最佳的栏目尺寸理想情况是每行 60 个字符左右，不少于 40 个字符，不超过 90 个字符。
书籍的 不完全是读一本书，我们可以达到上限，我们应该
保持每行 80 到 90 个字符。
除非您正在编写将在特定屏幕尺寸和旧显示器上运行的低级代码，否则我建议您遵循 gopher 标准，即每行 67 个字符。
好奇心：
find 。 -type f -name "*.c" -exec wc -L {} \; | 排序 -n | 少-NHere is a study for you:
I teach programming for more than 30 years, and during this time I accumulated 1823 source codes in C with various routines, from random small games to neural networks, compilers, educational softwares, automatically generated lex/yacc source codes, etc.
Following the Pareto Principle, 80% of those programs have lines smaller than 159 columns. So, to cut the lower 20% and the upper 20%, we have:
Now that is a range that gives you freedom. You don't want to limit your code to 80 columns just for the sake of it, because sometimes you will need nested loops, functions, or some indentation that will be easy to understand in a bigger line, and if you forcibly distort your logic to fit an arbitrary column width, you are not using the best logic.
Sometimes, on the other hand, the size of a line is an indicator that your logic could be better, and your line could be smaller; specially if you are not in a nested part of the code and you already crossed the limit of, say, 160 columns.
Based on my own experience and readability, I recommend you write your code aiming for 80 columns, but allowing until 120 columns of margin, and never crossing the 160 columns limit.
Also, we should consider the older experience of reading that exists: books. Books are typographically created to easy the reader's eye movement, and the best sized column according to professionals in the area is ideally around 60 characters per line, not less than 40, not more than 90.
Since coding is not exactly reading a book we can go for the upper limit, and we should
stay between 80 and 90 characters per line.
Unless you are programming low level code that will run in specific screen sizes and old monitors, than I would recommend you follow gopher standard, which is 67 characters per line.
Curiosity:
find . -type f -name "*.c" -exec wc -L {} \; | sort -n | less -N不考虑硬件限制以及我们阅读代码与自然语言的方式的任何差异，我认为将行数限制在 80 个字符左右的三个主要原因。
Disregarding hardware restrictions, and any differences in how we read code versus natural language, I see three primary reasons to limit lines to around 80 characters.
也许 80 个字符也是避免这些不良 getter 链的一个好点：
如果将其限制为 80 个字符，也许有人会本地化这些变量并执行 null 检查等，但也许大多数程序员会让它们换行到下一行。 我不知道
除此之外，正如starblue所说，80个角色已经很棒了。 这绝对应该纳入编码标准。
Maybe the 80 characters is also a good point to avoid these bad getter chains:
if you limit it to 80 characters, maybe someone would localize these variables and do null check etc, but maybe most programmers would let them wrap in the next row. i don't know
Beside that, 80 characters are great as starblue mentioned. This should defenitely goes into the coding standards.
我清楚地记得在某处读过（我认为是在敏捷文档中）最佳可读性文档的宽度应约为两个字母，或 60-70 个字符。 我认为旧终端的线宽部分来自于旧的印刷规则。
I distinctly remember reading somewhere (I think it was in Agile Documentation) that for optimal readability a document's width should be about two alphabets, or 60-70 characters. I think the old terminals' line width came in part from that old typographical rule.
如果您要打印代码，右侧边距选项旨在向您显示页面的宽度，并且之前的帖子表示它被设置为 80，因为这是 GUI 之前一直到打孔之前的历史行长度牌。
我最近在一些博客（不记得是什么博客）上看到建议增加 IDE 字体大小以提高代码质量，其背后的逻辑是，如果屏幕上适合的代码较少，您将编写较短的行，并且喊叫者功能。
在我看来，较短的行使阅读代码和调试代码变得更容易，因此我尝试保持行数较短，如果您必须设置限制以使自己编写更好的代码，那么选择适合您的代码 - 而且如果您更有效率的话较长的行可以随意增加页面大小，并且仅在宽屏幕上编写代码。
The right margin option is intended to show you the width of the page if you're going to print the code, and has previous posted said it was set to 80 because that's what the line length historically was before GUI all the way back to punch cards.
I've seen a recommendation on some blog recently (can't remember what blog) to increase you IDE font size in order to improve code quality, the logic behind it is that if less code fits on screen you'll write shorter lines and shouter functions.
In my opinion shorter lines make reading the code and debugging it easier, so I try to keep the lines short, if you have to set a limit to make yourself write better code then choose what works for you - also if you are more productive with longer lines feel free to increase the page size and code only on a wide screens.
正如一些人在其他答案中指出的那样，80 个字符限制的原因部分是历史原因（打孔卡、小屏幕、打印机等），部分是生物学原因（为了跟踪您所在的行，通常能够看到整个内容是件好事）无需转动头部）。
也就是说，请记住，我们仍然是人类，我们构建工具来解决我们自身的局限性。 我建议您忽略有关字符限制的整个争论，只编写有意义的内容，无论其长度如何，并使用可以帮助您正确跟踪行的 IDE 或文本编辑器。 在制表符与空格的争论中使用相同的缩进参数，以及缩进应该有多宽，我建议您使用缩进标记（最常见的是制表符），然后让人们配置自己的 IDE 或文本编辑器来显示它们因为他们觉得最舒服。
坚持每行固定数量的字符总是会让除了目标受众之外的所有人的情况变得更糟。 也就是说，如果您永远不会共享代码； 那么根本就没有理由进行这样的讨论。 如果您想共享代码，您可能应该让人们自己决定他们想要什么，而不是将您（或其他人）的理想强加给他们。
As some people have pointed out in other answers the reason for the 80 character limit is partly historical (punch cards, small screens, printers etc) and partly biological (to track what line you are in it's generally good to be able to see the entire line without needing to turn the head).
That said, please remember that we are still humans and we build tools to solve our own limitations. I propose you ignore the entire debate about character limitation and just write stuff that makes sense regardless of their length, and use an IDE or text editor that can help you keep track of the lines properly. Using the same argument for indentation in the tabs vs spaces debate, as well as the how wide should the indentations be I propose you use an indentation marker (most commonly the tab) and just have people configure their own IDE or text editors to display them as they find most comfortable to them.
Sticking with a fixed number of characters per line will always make things worse for everyone but the targeted audience. That said, if you will never share the code, ever; then there's really no reason to even have this discussion to begin with. Should you want to share the code, you should probably let people decide what they want on their own instead of forcing yours (or someone elses) ideals on them.
据我所知，80 个字符用作编码标准，以保持与命令行编辑器的兼容性（默认终端宽度通常为 80 个字符）。 对于现代 IDE 和大屏幕分辨率，80 个字符可能不是“最佳”，但对于许多开发人员来说，保持终端的可读性至关重要。 因此，80 个字符宽度不太可能很快被取代，成为代码宽度的事实标准。 要回答您的最后一个问题，是的，代码宽度以及任何其他会影响代码可读性的特征都应该在您的编码标准中得到解决。
To the best of my knowledge the 80 character is used as a coding standard to maintain compatibility with command line editors (default terminal width is typically 80 characters). With modern IDEs and large screen resolutions 80 characters is probably not "optimal", but for many developers maintaining readability in the terminal is essential. For that reason it is not likely that 80 character width will be replaced as the de facto standard for code width anytime soon. And to answer your final question, yes, code width as well as any other characteristic which will affect your code's readability should be addressed in your coding standards.
怜悯那些以后必须维护你的软件的程序员，并坚持 80 个字符的限制。
选择 80 的原因：
在笔记本电脑上可以使用较大的字体阅读
留出空间以便并排放置两个版本进行比较
在 IDE 中为导航视图留出空间
打印时不任意断行（也适用于电子邮件、网页等）< /p>
限制一行的复杂性
限制缩进，从而限制复杂性方法/函数的数量
，它应该是编码标准的一部分。
Have mercy on the programmers who have to maintain your software later and stick to a limit of 80 characters.
Reasons to prefer 80:
Readable with a larger font on laptops
Leaves space for putting two versions side by side for comparison
Leaves space for navigation views in the IDE
Prints without arbitrarily breaking lines (also applies to email, web pages, ...)
Limits the complexity in one line
Limits indentation which in turn limits complexity of methods / functions
Yes, it should be part of the coding standard.