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

Question

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

---

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

Answer 1

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

• 将代码复制到电子邮件,网页和书籍时避免包装.
• 并排查看多个源窗口或使用并排差异查看器.
• 提高可读性.窄代码可以快速读取,无需从一侧到另一侧扫描您的眼睛.

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

Answer 2

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

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

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

这是一个老式的Fortran声明:

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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列,我认为我的观点仍然存在,我只是选了一个坏榜样.它仍然证明在一行上放置多个语句可以提高可读性.

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

我有两个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版本.

Answer 11

人们说长长的代码往往很复杂.考虑一个简单的Java类:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

这是94个字符长,类名很短(按GWT标准).它很难在2行读取,并且在一行上非常易读.由于务实,因此允许"向后兼容",我会说100个字符是正确的宽度.

Answer 12

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

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

Answer 13

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

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

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

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

Answer 14

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

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

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

Answer 15

我已经将我的代码扩展到 100 个字符，这在我的 Macbook 上不到一半的屏幕上可以轻松容纳。120 个字符可能是行开始变得太长和太复杂之前的限制。你不想太宽，否则你鼓励复合语句和深度嵌套的控制结构。

右边距是大自然告诉您执行额外方法重构的方式。

Answer 16

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

Answer 17

作为我雇主的编码指南的作者,我将线路长度从80增加到132.为什么这个值？好吧,就像其他人指出的那样,80是许多旧硬件终端的长度.132也是!它是端子处于宽模式时的线宽.任何打印机也可以使用压缩字体在宽模式下制作硬拷贝.

不停留在80的原因是我宁愿

• 更喜欢具有标识符含义的较长名称
• 不打扰C中的结构和枚举的typedef(它们很糟糕,它们隐藏了有用的信息!如果你不相信它,请问Peter Deep der Linden的"Deep C Secrets"),所以代码struct FOO func(struct BAR *aWhatever, ...)不仅仅是typedef狂热分子的代码.

根据这些规则,只有80个字符/行会导致丑陋的线条包裹,而不是我的眼睛认为可接受的(主要是在原型和函数定义中).