“编程的真正英雄是编写否定代码的人。”
是什么意思？
#1 楼
这意味着通过删除冗余或使用更简洁的结构来减少代码行。例如，请参阅原始Apple Lisa开发人员团队的这一著名轶事：
当Lisa团队在1982年推动对其软件进行最终定型时，项目经理开始要求程序员每周提交一次表格，以报告其编写的代码行数。比尔·阿特金森（Bill Atkinson）认为这很愚蠢。在他将QuickDraw的区域计算例程重写为快六倍，缩短2000行的那一周，他在表格上加上了“ -2000”。再过几个星期，经理们不再要求他填写表格，他很高兴地遵守了。
评论
实现完美，不是在没有其他东西可添加时，而是在没有其他东西可取时-Antoine deSaint-Exupéry
–systempuntoout
2010-09-27在7:06
#LOC是衡量代码质量的好方法吗？我可以“缩小”任何C或C ++代码并显着减少行数，但是这将是一场噩梦。
– JBR威尔金森
2010-09-27在8:08
@systempuntout-然后出现了Einsten的“（科学理论）应该尽可能简单，但不要简单”
–乔纳森·戴（Jonathan Day）
2010-09-27 8:44
没有任何代码可以运行得更快，更可靠，需要的维护更少。 “有疑问时，把它挡出去！”
– TMN
2010-09-27 12:18
@JBRWilkinson：我想说一下关于代码简洁性的“最佳地方”。通常，越短越好，但是有时候代码会变得过于简洁，不容易被其他程序员理解。
–GordonM
2010-10-16 21:54
#2 楼
比尔·盖茨（Bill Gates）的一句话是用代码来衡量程序员的工作效率，就像用重量来衡量飞机的建造进度。轻描淡写的语言，并故意重新发明轮子以达到配额。评论
是的，这是任何度量标准的问题。一旦您使用它们来判断人们的表现，他们就会开始计算数字。
– Thilo
2010-09-27的5:59
有人真正使用过LOC作为性能指标吗？我只看到它用于“我们如何在这里谈论项目的错误？”之类的东西。
–迈克尔·伯格沃德（Michael Borgwardt）
2010-09-27 7:53
@迈克尔：是的。不幸的是。
–迈克尔·彼得罗塔（Michael Petrotta）
2010-09-27在8:24
一个为航天飞机的机载计算机编写代码的程序员告诉我，他必须考虑软件的重量！该软件是真实的（为此付出了金钱）；它在班车上；必须考虑到航天飞机上装载的所有物品的重量。通过代码权重衡量程序员生产力的第一个示例。 （不允许使用零，所以他指定了0.00001克，一切都令人满意。）
–马克·卢顿
2010-09-27 15:11
@杰伊：十年前，程序存储在打孔卡上。使用打孔卡时，软件的重量会为负值，因为打孔后卡的重量会更轻！
–马克·卢顿
2010-10-21 14:33
#3 楼
当我上高中时-是的，我们早在70年代就拥有计算机，尽管我们不得不使用石刀将它们用动物皮制成。规则是，获胜的程序将产生正确的输出，并且代码行乘以运行时间的乘积最小。也就是说，如果您的程序花费了100行代码并运行了5秒钟，则您的得分为500。如果其他人编写了90行代码并运行了6秒，则他的得分为540。低分获胜，例如高尔夫。它给我的印象是出色的评分系统，既简洁又表现出色。
但是技术上符合获奖标准的参赛作品被取消资格。问题是要打印一个所有小于100的质数的列表。取消资格的条目是这样的（当时大多数学生当时都在使用BASIC）：
>撰写该条目的学生指出，它不仅简短而且非常有效，而且即使对编程知识很少的人，该算法也应该显而易见，从而使该程序具有很高的可维护性。
评论
更多的证据表明，对代码行进行计数是一个非常可衡量的指标：-)
–paulecoyote
2010-10-20在16:08
那个BASIC程序很棒！老师取消了该计划的资格，这真是令人沮丧。毕竟，在实际编程中肯定可以找到查找表（该程序有些类似）。
– Noctis Skytower
2010-10-21 2:37
明智的老师可能已经接受了此BASIC程序，并用它来强调正确设置SRS的重要性。让我想起了一个棒球教练，他对他的球队感到沮丧，以示向他们展示如何打球，他接过球拍，连续三击而又不甘示弱。 *****正在玩。现在就击球并正确玩吧！”。还让我想起了写过“创造看到创造者并脸红了”并赢得“葡萄酒”征文比赛的人。
–Nav
2011年8月26日在8:13
@Nav：让我想起了以相同的方式开始的类似故事。然后教练向空中掷球，挥杆并未击中。他再次将它扔向空中，摇摆并错过。他第三次将它扔向空中，挥杆并未击中。然后他对团队说：“瞧，那就是你应该如何投球！” （我不知道这个故事可能与软件开发有关。）
–杰伊
11年8月26日在20:20
如果我没有资格参加比赛，我会很沮丧。确定性问题值得确定性解决方案，对吗？当我编写“ Hello World”应用程序时，我不会编写代码来检查我是否正确拼写了“ Hello”。
–柯克·布罗德赫斯特（Kirk Broadhurst）
2011-09-28 0:44
#4 楼
这是嘲讽。如果每条平均编码行花费您$ N，那么编码“负行”肯定是赢家。这意味着，作为实用建议，完成任务的小代码总比大代码好得多。在其他所有条件相同的情况下执行相同操作的代码。
评论
我知道您来自哪里，但是简洁，易于理解的小尺寸代码却很难一achieved而就。通常将其编写为使其工作（许多行），针对速度进行优化（减少一些行）并针对维护/可读性进行优化（减少行数）。具有长投资回报率的实际成本是第二步和第三步，因此通常会完全忽略它们。就像“便宜，快速和优质-您可以选择两个”一样。
– RickiG
2010-09-27 10:49
实际上，针对维护/可读性进行优化的IME实际上可以提高LOC，因为重写代码以使其更具自记录性也往往使其更加冗长。
–浏览
2010-09-27 10:56
@Visage：“ ...其他所有条件都相同”。
–伊拉克·巴克斯特
2010-09-27 14:10
我认为，要点是，简明代码和冗长代码之间的所有其他条件都不相同。
– Tomas Narros
2010-09-27 16:20
平均代码行花费$ N的原因是因为您首先花费时间编写X行。然后，经过几次迭代，最终产品减少了Y行。因此，（X-Y）剩余的行似乎非常昂贵，因为重构的大屠杀削减了所有麻烦。
–克里斯
2010-10-20 18:54
#5 楼
用更少的代码编写相同的程序是每个人的目标。如果一个程序要花200 LOC的代码来编写，而我用150编写，则我写了-50 LOC。所以我写了负面代码。
评论
此外，减少LOC意味着您可以减少错误并轻松发现它们-
– LucaB
2010-09-27 12:52
对于Haskell和其他可以压缩为随机噪声的语言而言，情况并非如此。 :)
– Macke
2010-09-28 16:57
当然，我的意思不是“压缩代码”，而是编写有效的算法以减少LOC :) +1为您注释。
– LucaB
2010-09-29 10:35
#6 楼
从历史上看，Thilo的答案可能是最准确的，但是“负代码”隐喻也可以包括性能和内存使用-奖励将执行或分配推迟到实际需要之前的工作。这种“精打细算”的思想产生了这样的“绕公理，例如“什么都不做总比做某件事更快”，“最快的代码是永远不会执行的代码”和“您可以将其推迟足够长的时间，您可能永远不必这样做”（指的是推迟昂贵的操作，直到实际需要为止）。问题。如果您可以重新定义问题/输入域，以使“粘性问题＃3”绝对不可能，那么您就不必花费时间或代码来处理粘性问题＃3。您已经通过优化设计消除了代码。
评论
我最有生产力的日子之一就是扔掉1000行代码。 -肯·汤普森相关：quora.com/How-many-lines-of-codes-do-professional-program ...