是否有正当理由在当天和年龄的代码文件中强制执行最大宽度为80个字符？

认真.在一台22英寸的显示器上,它只能覆盖屏幕的四分之一.我需要一些弹药来制定这个规则.

---

我不是说不应该有限制; 我只是说,80个字符非常小.

1> Will Harris..：

---

我认为将代码保存到80(或79)列的做法最初是为了支持人们在80列哑终端或80列打印输出上编辑代码而创建的.这些要求现在已基本消失,但仍有正当理由保留80列规则:

将代码复制到电子邮件,网页和书籍时避免包装.

并排查看多个源窗口或使用并排差异查看器.

提高可读性.窄代码可以快速读取,无需从一侧到另一侧扫描您的眼睛.

我认为最后一点是最重要的.虽然显示器在过去几年的尺寸和分辨率都有所增长,但眼睛却没有.

---

问题是迫使人们保持线路长度短,他们倾向于使用不那么有意义的名字.

---

@steffenj:实际上,书籍往往每行约66个字符(虽然这取决于其他参数,但有所不同),因为较长的行*会使阅读变得更加困难.可以争论最大_code_行长度,但由于历史和实际原因,80是方便的.

---

他们可能"已基本消失",但并非完全消失.我倾向于使用两种不同的设置:1)在连接到远程机器的ssh窗口中.默认为80个字符宽.2)在Visual Studio中,并排放置两个面板,这样我就可以同时看到header和cpp文件.

---

我认为80列执行者的问题在于他们忘记了代码在垂直方向上增长.你会遇到同样的问题,但是在这个现代代码的垂直方向和顶部看起来很糟糕,当你必须将单个语句分成两行或有时多达四行或五行时.它不具有可读性.使用现代代码,我的意思是描述性变量名称和限定继承,名称空间,类等.请停止80列非句,改为使用常识.120更好,但也不应该是一个规则.

---

我发现关于可读性的评论非常有趣,因为我真正讨厌打印的编程文章/书籍/ ...是,用于代码示例的短行是如此极难阅读.将某些内容移动到新行可能很有意义,但是分组应该在逻辑上进行,递归地解析表达式,而不是因为输出设备意外地达到了它的限制.我发现,施加这种狭窄限制的设备不太适合显示代码.

---

我在@Enno,一个更宽的屏幕意味着两个80列文件的空间,而不是一个大多数80列,一个很少的长线和一个充满未使用空间的编辑器:)它也很重要当前的编辑器*do*能够水平滚动,所以如果一行*应该*超过80个字符,那么保留它是完全安全的.

2> John Carter..：

---

80列文本格式的起源早于80列终端 - IBM打卡可以追溯到1928年!这让人想起美国铁路轨距由罗马英国的战车车轮宽度决定的(伪造)故事.

我有时觉得它有点紧缩,但是有一些标准限制是有意义的,所以它是80列.

这是Slashdot所涵盖的相同主题.

这是一个老式的Fortran声明:

3> Craig Day..：

---

如今80个字符是一个荒谬的限制.将代码行拆分到合理的位置,而不是根据任意字符限制.

4> Kibbee..：

---

你应该为每个没有22英寸宽屏显示器的人做这件事.就个人而言,我使用17英寸4:3显示器,我发现它足够宽.但是,我也有3个这样的显示器,所以我仍然有很多可用的屏幕空间.

不仅如此,如果线条太长,人眼实际上在阅读文本方面存在问题.在你所在的哪条线路上迷路太容易了.报纸横跨17英寸(或类似的东西),但你看不到它们在页面上一直写着,杂志和其他印刷品一样.如果你让列保持狭窄,它实际上更容易阅读.

---

不是在混音中添加缩进时.如果你每个缩进使用4个空格,并且你的名字是:namespace-> class-> method-> if-> for,那就是你空间的1/5.

---

然而,阅读散文与阅读代码并不相同.

---

报纸+1,很好的例子.@Atario,阅读GOOD代码非常像阅读散文.

5> Sam Hasler..：

---

如果您有一系列重复较小变化的语句,则可以更容易地看到相似性和差异,如果它们被分组为行,以便差异垂直对齐.

我认为,如果我将它分成多行,那么以下内容的可读性要大得多:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

更新:在评论中,有人建议这将是一种更简洁的方式来做上述事情:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

虽然它现在符合80列,我认为我的观点仍然存在,我只是选了一个坏榜样.它仍然证明在一行上放置多个语句可以提高可读性.

---

事实上,我需要横向滚动两个例子中的第一个,这证明了关于更短线条更好的品脱:-)

---

通过说,线与线之间只有很小的差异,你也说,有很多冗余的代码.删除其中一些可能会显着减少列数,仍然垂直对齐.

6> 小智..：

---

以默认尺寸打印等宽字体是(在A4纸上)80列乘66行.

7> 小智..：

---

我利用更大屏幕的优势,在彼此旁边有多个代码片段.

你不会从我那里得到任何弹药.事实上,我不愿意看到它发生了变化,因为在紧急情况下我仍然会看到我需要从文本控制台更改代码的罕见情况.

8> Loren Pechte..：

---

超长线条更难阅读.仅仅因为你可以在显示器上获得300个字符并不意味着你应该把线条变长.除非你没有选择(一个需要大量参数的调用),否则300个字符对于语句来说也太复杂了.)

我使用80个字符作为一般规则,但我会超越它,如果强制执行它将意味着在不合适的位置放置换行符.

9> 小智..：

---

我强制要求保持80个字符的唯一内容是我的评论.

就个人而言......我正在把所有的脑力(对于那里的东西都很少)用于编码,当我可以把时间花在下一个功能上时,我必须回过头来在80个字符的限制内打破一切是很痛苦的. .是的,Resharper可以为我做这件事我想但是然后它让我感到不安,第三方产品正在对我的代码布局做出决定并改变它("请不要将我的代码分成两行HAL.哈尔？" ).

也就是说,我在一个相当小的团队工作,我们所有的监视器都相当大,所以担心我的同事程序员的困扰并不是一个大问题.

看起来虽然有些语言为了更多的利益而鼓励更长的代码行(如果那么陈述的话是简短的话).

10> ConcernedOfT..：

---

我有两个20"1600x1200显示器,我坚持80列,因为它允许我并排显示多个文本编辑器窗口.使用'6x13'字体(传统.xterm字体)80列占用480像素加上滚动条这允许在1600x1200显示器上有三个这种类型的窗口.在Windows上,Lucida Console字体不会这样做(最小可用尺寸为7像素宽)但是1280x1024显示器将显示两列和一台1920x1200的显示器(如HP LP2465)将显示3.它还会为Visual Studio中的各种浏览器,属性和其他窗口留出一些空间.

此外,很长的文本行很难阅读.对于文本,最佳值为66个字符.有一点,过长的标识符开始适得其反,因为它们使得难以一致地布置代码.良好的布局和缩进提供了关于代码结构的可视提示,并且一些语言(Python浮现在脑海中)明确地使用缩进.

但是,Java和.Net的标准类库往往具有非常长的标识符的优势,因此无法保证能够执行此操作.在这种情况下,使用换行符布局代码仍然有助于使结构显式化.

请注意,您可以在此处获取'6x13'字体的Windows版本.

11> 小智..：

---

其他答案已经很好地总结了一些事情,但是当你想要将一些代码复制并粘贴到电子邮件中,或者如果不是代码然后是差异时,也值得考虑.

这是一个"最大宽度"有用的时候.

12> pappes..：

---

您不是唯一一个维护代码的人.

下一个人可能有一个17英寸的屏幕或可能需要大字体来阅读文本.限制必须在某处,由于以前的屏幕限制,80个字符是惯例.你能想到任何新的标准(120)和为什么使用那个其他的好主意"那是什么适合我的显示器在Xpt字体？"

请记住,每条规则都有例外情况,所以你有一个特定的代码行或代码块,超过80个字符然后成为反叛者.

但是先花时间思考"这个代码真的那么糟糕,它不能生活在80个字符之内吗？"

13> Ali..：

---

在Linux编码标准中,它们不仅保持80个字符的限制,而且还使用8个空格缩进.

部分原因是,如果您达到了正确的边距,则应考虑将缩进级别移动到单独的函数中.

这将使代码更清晰,因为无论缩进长度如何,都很难读取具有许多嵌套控件结构的代码.

---

如何使用多个函数调用读取代码？当然这两种方法之间存在妥协......

14> Jonas..：

---

我想知道这可能会在这个时代引起更多问题.请记住,在C(以及可能的其他语言)中,存在函数名称可以有多长的规则.因此,您经常会在C代码中看到非常难以理解的名称.好消息是他们没有占用太多空间.但是每当我用C#或Java等语言查看代码时,方法名称通常都很长,这使得将代码保持在80个字符长度几乎是不可能的.我认为今天80个字符无效,除非您需要能够打印代码等.