blocks|key|1596572|text|80列文本格式的起源早于80列终端--+IBM穿孔卡可以追溯到1928，它在1725中的传统是纸带！这让人想起(apocryphal)的故事，在罗马的英国，美国的铁路轨距是由车轮的宽度决定的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1596573|我有时发现它有点狭窄，但有一些标准限制是有意义的，所以80列是有意义的。|1596574|这里是Slashdot所涵盖的相同主题。|1596575|下面是一句老式的Fortran语句：|1596576|​|1596577|📷|atomic|1596578|1596579|entityMap|0|LINK|mutability|MUTABLE|url|http://www-03.ibm.com/ibm/history/history/year_1928.html|1|https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/|2|http://www.snopes.com/history/american/gauge.asp|3|http://ask.slashdot.org/article.pl?sid=07/07/07/1931246|4|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/669360e334cf48c04796bf78361ac348.jpeg|imageAlt^0|V|4|0|12|4|1|1J|C|2|0|0|3|8|3|0|0|0|0|1|4|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@$A|1A|B|1B|1|1C]|$A|1D|B|1E|1|1F]|$A|1G|B|1H|1|1I]]|C|$]]|$1|D|3|E|5|6|7|1J|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|H|3|I|5|6|7|1O|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1P|8|@]|9|@]|C|$]]|$1|L|3|M|5|N|7|1Q|8|@]|9|@$A|1R|B|1S|1|1T]]|C|$]]|$1|O|3|K|5|6|7|1U|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1V|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]|X|$5|S|T|U|C|$V|Y]]|Z|$5|S|T|U|C|$V|10]]|11|$5|S|T|U|C|$V|12]]|13|$5|14|T|15|C|$16|17|18|-4]]]]

The origin of 80-column text formatting is earlier than 80-column terminals -- the IBM punch card dates back to <a href="http://www-03.ibm.com/ibm/history/history/year_1928.html" rel="nofollow noreferrer">1928</a>, and its legacy to paper tapes in <a href="https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/" rel="nofollow noreferrer">1725</a>! This is reminiscent of the <a href="http://www.snopes.com/history/american/gauge.asp" rel="nofollow noreferrer">(apocryphal)</a> story that the US railway gauge was determined by the width of chariot wheels in Roman Britain.
I sometimes find it a bit constricting, but it makes sense to have some standard limit, so 80 columns it is.
Here's the same topic covered by <a href="http://ask.slashdot.org/article.pl?sid=07/07/07/1931246" rel="nofollow noreferrer">Slashdot</a>.
And here's an old-school Fortran Statement:
<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/5/58/FortranCardPROJ039.agr.jpg/600px-FortranCardPROJ039.agr.jpg" alt="FORTRAN punch card" />

blocks|key|1810923|text|如今，80个字符是一个荒谬的限制。在有意义的地方拆分代码行，而不是根据任何任意的字符限制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810924|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

80 characters is a ridiculous limit these days. Split your code lines where it makes sense, not according to any arbitrary character limit.

blocks|key|1810497|text|你应该这样做是为了所有没有22英寸宽屏显示器的人。就我个人而言，我使用的是一台17英寸的4:3显示器，我发现这已经足够宽了。然而，我也有3个这样的显示器，所以我仍然有很多可用的屏幕空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810498|不仅如此，如果行数太长，人眼在阅读文本时也会遇到问题。你很容易迷失在哪一条线路上。报纸有17英寸宽(或类似的东西)，但你看不到它们在整个页面上都写着，杂志和其他印刷品也是如此。如果你保持列的窄，它实际上更容易阅读。|1810499|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You should just do it for the sake of everyone who doesn't have a 22 inch widescreen monitor. Personally, I work on a 17 inch 4:3 monitor, and I find that more than sufficiently wide. However, I also have 3 of those monitors, so I still have lots of usable screen space. 

Not only that, but the human eye actually has problems reading text if the lines are too long. It's too easy to get lost in which line you are on. Newspapers are 17 inches across (or somethign like that), but you don't see them writing all the way across the page, same goes for magazines and other printed items. It's actually easier to read if you keep the columns narrow.

blocks|key|1596676|text|以默认大小打印等宽字体(在A4纸张上)是80列乘66行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1596677|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Printing a monospaced font at default sizes is (on A4 paper) 80 columns by 66 lines.

blocks|key|1810173|text|我利用较大屏幕的优势，让多段代码彼此相邻。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810174|你不会从我这里得到任何弹药的。事实上，我不愿意看到它发生变化，因为在紧急情况下，我仍然看到需要从文本控制台更改代码的极少数情况。|1810175|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I use the the advantage of bigger screens to have multiple pieces of code next to eachother.

You won't get any ammo from me. In fact, I'd hate to see it changed since in emergencies I still see rare cases where I need to change code from a text-console.

blocks|key|1810833|text|超长的队伍更难读懂。仅仅因为你可以在显示器上显示300个字符，并不意味着你应该把这些行写得那么长。300个字符对于一个语句来说也太复杂了，除非你别无选择(一个需要一大堆参数的调用)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810834|我使用80个字符作为一般规则，但如果强制执行它将意味着在不需要的位置放一个换行符，我将超越这一点。|1810835|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Super-long lines are harder to read. Just because you can get 300 characters across on your monitor doesn't mean you should make the lines that long. 300 characters is also way too complex for a statement unless you have no choice (a call that needs a whole bunch of parameters.)

I use 80 characters as a general rule but I'll go beyond that if enforcing it would mean putting a line break in an undesirable location.

blocks|key|1810948|text|我唯一要求保持在80个字符以内的就是我的评论。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810949|就我个人而言……我把我所有的脑力(仅有的一点)都投入到正确的编码上，当我可以把时间花在下一个函数上时，不得不回到80个字符的限制来打破一切，这是一件痛苦的事情。是的，我想Resharper可以为我做到这一点，但它让我有点害怕，因为第三方产品正在决定我的代码布局并对其进行更改(“请不要把我的代码拆成两行，哈尔。哈尔？”)。|1810950|也就是说，我在一个相当小的团队中工作，我们所有的监视器都相当大，所以担心我的程序员同事的困扰并不是一个大问题。|1810951|尽管有些语言鼓励使用更长的代码行，以获得更高的性价比(简写为if+then语句)。|1810952|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The only thing I enforce to stay within 80 chars is my commenting.

Personally...I'm devoting all my brain power (what little there is) to coding right, it's a pain to have to go back and break everything up at the 80 char limit when I could be spending my time on the next function. Yes, Resharper could do it for me I suppose but then it freaks me out a little that a 3rd party product is making decisions on my code layout and changes it ("Please don't break my code into two lines HAL. HAL?").

That said, I do work on a fairly small team and all of our monitors are fairly large so worrying about what bothers my fellow programmers isn't a huge concern as far as that goes.

Seems though some languages encourage longer lines of code for the sake of more bang for the buck (short hand if then statements).

blocks|key|1596524|text|我有两个20英寸的1600x1200显示器，我坚持使用80列，因为它允许我并排显示多个文本编辑器窗口。使用'6x13‘字体(传统xterm字体)+80列占480像素加上滚动条和窗口边框。这允许在1600x1200监视器上有三个这种类型的窗口。在windows上，Lucida控制台字体不能做到这一点(最小可用尺寸为7像素宽)，但1280x1024的显示器将显示两列，1920x1200的显示器(如HP+LP2465+)将显示3。它还将为Visual+Studio中的各种资源管理器、属性和其他窗口留出一些空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1596525|此外，很长的文本行很难阅读。对于文本，最佳长度为66个字符。有一点，过长的标识符开始适得其反，因为它们使代码难以连贯地布局。良好的布局和缩进提供了关于代码结构的视觉提示，一些语言(想到了Python)为此显式地使用了缩进。|1596526|然而，Java和.Net的标准类库往往具有非常长的标识符，因此不一定能保证能够做到这一点。在这种情况下，使用换行符布局代码仍然有助于使结构清晰。|1596527|请注意，您可以获得windows版本的'6x13‘字体Here。|1596528|entityMap|0|LINK|mutability|MUTABLE|url|http://h10010.www1.hp.com/wwpc/uk/en/sm/WF05a/382087-382087-64283-444767-444767-1844961.html|1|http://www.hassings.dk/lars/fonts.html^0|5I|9|0|0|0|0|R|4|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]]|C|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]]]

I have two 20" 1600x1200 monitors and I stick to 80 columns because it lets me display multiple text editor windows side-by-side. Using the '6x13' font (the trad. xterm font) 80 columns take up 480 pixels plus the scrollbar and window borders. This allows one to have three windows of this type on a 1600x1200 monitor. On windows the Lucida Console font won't quite do this (the minimun usable size is 7 pixels wide) but a 1280x1024 monitor will display two columns and a 1920x1200 monitor such as an <a href="http://h10010.www1.hp.com/wwpc/uk/en/sm/WF05a/382087-382087-64283-444767-444767-1844961.html" rel="nofollow noreferrer">HP LP2465</a> will display 3. It will also leave a bit of room at the side for the various explorer, properties and other windows from Visual Studio.

Additionally very long lines of text are hard to read. For text the optimum is 66 characters. There is a point where excessively long identifiers start to be counterproductive because they make it hard to lay out code coherently. Good layout and indentation provides visual cues as to the code structure and some languages (Python comes to mind) use indentation explicitly for this.

However, The standard class libraries for Java and .Net tend to have a preponderance of very long identifiers so one cannot necessarily guarantee to be able to do this. In this case, laying out code with line-breaks still helps to make the structure explicit. 

Note that you can get windows versions of '6x13' fonts <a href="http://www.hassings.dk/lars/fonts.html" rel="nofollow noreferrer">Here</a>.

blocks|key|1810504|text|其他答案已经很好地总结了这一点，但当您可能想要将一些代码复制并粘贴到电子邮件中时，也值得考虑，或者如果不是代码，那么就比较一下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810505|这时候有一个“最大宽度”是有用的。|1810506|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The other answers already summed things up nicely, but it is also worth considering when you might want to copy &amp; paste some code into an email, or if not code then a diff.

That's a time when having a "max width" is useful.

blocks|key|1596741|text|人们说长行代码往往很复杂。考虑一个简单的Java类：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1596742|public+class+PlaintiffServiceImpl+extends+RemoteServiceServlet+implements+PlaintiffService+{|code-block|syntax|javascript|1596743|这是94个字符的长度，并且类名非常短(按照GWT标准)。它很难在两行上阅读，但在一行上非常容易阅读。出于实际考虑并允许“向后兼容”，我认为100个字符的宽度是正确的。|1596744|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

People say long lines of code tend to be complex. Consider a simple Java class:

<pre><code>public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {
</code></pre>

This is 94 characters long and the class name is quite short (by GWT standards). It would be difficult to read on 2 lines and it is very readable on one line.
Being pragmatic about it and thus allowing "backwards compatibility", I'd say 100 characters is the right width.

blocks|key|1596256|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1596257|下一个这样做的人可能有一个17英寸的屏幕，或者可能需要大字体来阅读文本。由于之前的屏幕限制，限制必须在某个地方，80个字符是惯例。你能想到任何新的标准(120)吗?为什么使用另一个标准是一个好主意，然后“这就是适合我的显示器的Xpt字体？”|1596258|记住，每条规则都有例外，所以如果你有一行或一段代码，超过80个字符就是一个叛逆者。|1596259|但是，先花点时间想想“这段代码真的那么糟糕，不能在80个字符以内吗？”|1596260|entityMap^0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|I|7|@]|8|@]|9|$]]|$1|A|3|B|4|5|6|J|7|@]|8|@]|9|$]]|$1|C|3|D|4|5|6|K|7|@]|8|@]|9|$]]|$1|E|3|F|4|5|6|L|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|M|7|@]|8|@]|9|$]]]|H|$]]

You are not the only person who is going to maintain your code.

The next person who does might have a 17" screen or might need large fonts to read the text. The limit has to be somewhere and 80 chars is the convention due to previous screen limitations. Can you think of any new standard (120) and why it is a good idea to use that other then "that's what fits on my monitor at Xpt font?"

Remember, there are always exceptions to every rule so it you have a particular line or block of code that makes sense to be more than 80 chars then be a rebel.

But take the time first to think "is this code really that bad that it can not live within 80 chars?"

blocks|key|1810985|text|在Linux编码标准中，它们不仅保持80个字符的限制，而且还使用8个空格缩进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810986|部分原因是，如果达到了右边距，就应该考虑将缩进级别移到单独的函数中。|1810987|这将使代码更清晰，因为无论缩进长度如何，都很难阅读具有许多嵌套控制结构的代码。|1810988|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

In the Linux coding standard, not only do they keep the 80 character limit, but they also use 8 space indentation.

Part of the reasoning is that if you ever reach the right margin, you should consider moving an indentation level into a separate function.

This will make clearer code because regardless of indentation lengths, it is harder to read code with many nested control structures.

blocks|key|1811070|text|我已经把我的代码扩展到100个字符，在我的Macbook上不到一半的屏幕上就能很好地适应。120个字符可能是行变得太长和复杂之前的限制。你不会想要太宽，否则你会鼓励复合语句和深度嵌套的控制结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1811071|右边距是自然告诉您执行extra+method+refactoring的方式。|offset|length|1811072|entityMap|0|LINK|mutability|MUTABLE|url|http://www.refactoring.com/catalog/extractMethod.html^0|0|B|O|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

I've widened my code out to 100 characters which fits comfortably in less than half my screen on my Macbook. 120 characters is probably the limit before lines start to get too long and complex. You don't want to get too wide else you encourage compound statements and deeply nested control structures.

The right margin is nature's way of telling you to perform an <a href="http://www.refactoring.com/catalog/extractMethod.html" rel="noreferrer">extra method refactoring</a>.

blocks|key|1811086|text|我想知道在这个时代，这会不会造成更多的问题。请记住，在C语言(可能还有其他语言)中，函数名可以有多长的规则。因此，您经常会在C代码中看到很难理解的名称。好消息是它们不会占用太多空间。但每次我查看C#或Java等语言的代码时，方法名称通常都很长，这使得将代码长度保持在80个字符以内几乎是不可能的。我不认为80个字符在今天是有效的，除非你需要能够打印代码，等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1811087|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I wonder if this might cause more problems in this day and age. Remember that in C (and possibly other languages) there are rules for how long a function name can be. Therefore, you often see very hard-to-understand names in C code. The good thing is that they don't use a lot of space. But every time I look at code in some language like C# or Java the method names are often very long, which makes it close to impossible to keep your code at a 80 characters length. I don't think 80 characters are valid today, unless you need to be able to print the code, etc.

blocks|key|1810843|text|正如其他人所说，我认为它最适合(1)打印和(2)垂直并排显示多个文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810844|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As others have said, I think it's best for (1) printing and (2) displaying multiple files side by side vertically.

blocks|key|1810990|text|我喜欢将宽度限制在100个字符左右，以便在宽屏显示器上支持两个SxS编辑器。我不认为有任何好的理由限制恰好80个字符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1810991|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I like to limit my width to 100 chars or so to allow two SxS editors on a widescreen monitor. I don't think that there is any good reason for a limit of exactly 80 chars anymore.

blocks|key|1811061|text|对于这个问题，已经有很多不错的答案，但值得一提的是，在您的IDE中，左边可能有一个文件列表，右边可能有一个函数列表(或任何其他配置)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1811062|你的代码只是环境的一部分。|1811063|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

There's already a lot of good answers to this, but it's worth mentioning that in your IDE you might have a list of files on the left, and a list of functions on the right (or any other configuration).

You're code is just one part of the environment.

blocks|key|1596737|text|使用比例字体。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1596738|我是认真的。我通常可以在不牺牲可读性和可打印性的情况下，在一行中获得100-120个字符的等价物。事实上，使用好的字体(例如，Verdana)和语法着色甚至更容易阅读。这在几天内看起来有点奇怪，但你很快就会习惯的。|1596739|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Use proportional fonts.

I'm serious. I can usually get the equivalence of 100-120 characters in a line without sacrificing readability or printability. In fact it's even easier to read with a good font (e.g., Verdana) and syntax coloring. It looks a little strange for a few days, but you quickly get used to it.

blocks|key|1596673|text|我整天都在并排学习，而且我也没有一台22英寸的显示器。我不知道我会不会。当然，喜欢使用箭头编码和300字符行的只写程序员对此并不感兴趣。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1596674|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'm diffing side-by-side all day long and I don't have a freakin' 22 inch monitor. I don't know if I ever will. This, of course, is of little interest to write-only programmers enjoying arrow-coding and 300-char lines.

blocks|key|1595956|text|对于我自己的代码，我实际上遵循了类似的规则，但这只是因为要将代码打印到A4页面-+80列对于我想要的字体大小来说是合适的宽度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1595957|但这只是个人喜好，可能不是你想要的(因为你想让弹药走另一条路)。|1595958|你为什么不质疑这个限制背后的原因呢--说真的，如果没有人能提出一个很好的理由来解释为什么会这样，那么你就有一个很好的理由将它从你的编码标准中删除。|1595959|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I actually follow a similar rule for my own code but only because of printing code to an A4 page - 80 columns is about the right width for my desired font size.

But that's personal preference and probably not what you were after (since you want ammo to go the other way).

What don't you question the reasoning behind the limit - seriously, if no-one can come up with a good reason why it's so, you have a good case for having it removed from your coding standards.

blocks|key|1811089|text|是的，因为即使在这个时代，我们中的一些人仍然在终端(ok，主要是终端仿真器)上编码，而显示器只能显示80个字符。所以，至少对于我所做的编码来说，我真的很欣赏80字符的规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1811090|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes, because even in this day and age, some of us are coding on terminals (ok, mostly terminal emulators), where the display can only display 80 chars. So, at least for the coding I do, I really appreciate the 80 char rule.

blocks|key|1596651|text|如果我们有一个these，我们就不会有这个讨论了！;-)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1596652|但认真地说，人们在答案中提出的问题是相当合理的。然而，最初的海报并不是反对限制，只是说80列太少了。|1596653|通过电子邮件发送代码片段的问题有一些优点。但考虑到大多数电子邮件客户端对预先格式化的文本所做的坏事，我认为换行只是您的问题之一。|1596654|至于打印，我通常发现100个字符行可以非常舒适地放在打印的页面上。|1596655|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/112996/what-toolapplicationwhatever-do-you-wish-existed#113226^0|7|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

If we had one of <a href="https://stackoverflow.com/questions/112996/what-toolapplicationwhatever-do-you-wish-existed#113226">these</a>, we wouldn't be having this discussion! ;-)

But seriously the issues that people have raised in their answers are quite legitimate. However the original poster was not arguing against a limit, merely that 80 columns is too few.

The issue of emailing code snippets has some merit. But considering the evil things that most email clients do to pre-formatted text I think that line wrapping is only one of your problems.

As for printing I usually find that 100 character lines will very comfortably fit onto a printed page.

blocks|key|1811096|text|我尽量将我的行数控制在80列以下。最重要的原因是当我在命令行工作时，我经常使用grep和less来浏览我的代码。我真的不喜欢终端打破长源码的方式(毕竟它们不是为这项工作而生的)。另一个原因是，我发现如果所有东西都放在一行中，而不是被编辑器打断，它看起来会更好。例如，让长函数调用的参数彼此之间很好地对齐，以及类似的东西。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1811097|entityMap^0|13|4|18|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

I try and keep my lines below 80 columns. The strongest reason is that i often find myself using <code>grep</code> and <code>less</code> to browse my code when working at the command-line. I really don't like how terminals are breaking long source lines (they after all aren't made for that job). Another reason is that i find it looks better if everything fits into the line and isn't broken by the editor. For example having parameters of long function calls nicely aligned below each other and similar stuff.

blocks|key|1811099|text|我们最近做了一项调查。几乎每个人都在gnome终端中使用vim，如果我们进行垂直拆分，则标准字体大小和屏幕分辨率为1280x1024的列数为78。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1811100|因此，我们都同意一个列数为(大约)+75个字符的编码标准。没问题的。|1811101|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

We did a survey recently. Almost everyone uses vim inside an gnome-terminal, and if we do a vertical split the column count is 78 as standard font size and screen resolution 1280x1024. 

So we all agreed to a coding standard with a column count of (around) 75 characters. It's ok.

Seriously. On a 22" monitor, it only covers maybe a quarter of the screen. I need some ammo to axe down this rule.

<hr>

I'm not saying that there shouldn't be a limit; I'm just saying, 80 characters is very small.

Is there a valid reason for enforcing a maximum width of 80 characters in a code file, this day and age?

Visual Studio

Python

Linux

Java

我是认真的。在一台22英寸的显示器上，它可能只覆盖了四分之一的屏幕。我需要一些弹药来打破这条规则。我不是说不应该有限制；我只是说，80个字符是非常小的。

问在代码文件中强制最大宽度为80个字符，这一天和时间是否有合理的理由？
EN

回答 24

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在代码文件中强制最大宽度为80个字符，这一天和时间是否有合理的理由？EN

回答 24

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在代码文件中强制最大宽度为80个字符，这一天和时间是否有合理的理由？
EN