为什么不使用的代码应该被删除？
我已经多次听说，必须从项目中删除未使用的代码。 然而，我不清楚“为什么？”。
我不删除的要点是：
- 代码已经写好了，努力了
- 代码可以在同步和真实环境中testing
- 如果组织良好（分组，分离包，松散耦合等），它不会干扰整体代码分析或重构
- 代码可能在未来使用
- 删除后，作者可能会感到不舒服
有人可以解释删除（或保留）未使用的代码的优点吗？
提前致谢！
这里有一些原因，为什么不使用的代码应该被删除：
-
对于任何一个从事项目工作的人来说，他们不仅要了解工作规范，还要了解未使用的材料。 这是浪费时间，造成混乱。
-
有一种危险是，在某个时候有人会做出一个不经意间涉及“hibernate”的代码，并可能引入错误。 我知道这是发生在我工作的项目上。
-
任何代码的维护都是一个pipe理负担。 通过保留旧的冗余代码来增加负担。 例如，在主分支中合并更改变得更困难，因为有更多的代码需要处理，而且更可能出错。
-
随着时间的推移，越来越多的旧的未使用的代码被添加到代码库中。 这增加了混淆，潜在的误解和pipe理开销。
-
未使用的代码再次被使用的可能性是不太可能的。 随着时间的推移重新使用的可能性减less。 如果要删除的代码被认为是足够重要的，那么代码就可以被分支并logging下来。
-
编码人员可能对代码可能有很多努力的个人感受是可以理解的。 但是专业的一部分要求这些想法必须为了更好的利益而放在一边。 时间代表没有人，在有效的代码库中没有保存历史代码的地方。
@suspectus做了很好的介绍删除代码的理由; 我想解决你个人的子弹保持代码。
- 代码已经写好了，努力了
但是，如果已经编写的代码没有被使用，这只是没有（未来）价值的成本。 这是努力投入的努力，保留这些努力的未使用的产品并不能证实这些努力。 我们保留代码是因为它是有用的，现在，不是作者的努力的某种纪念。
- 代码可以在同步和真实环境中testing
对不起，我不知道你的意思。
- 如果组织良好（分组，分离包，松散耦合等），它不会干扰整体代码分析或重构
如果存在于代码库中，则无论组织得如何，都会造成维护和理解的负担。 诚然，它可以被组织起来，以减轻负担，但是如果它消失了，那就完全没有任何负担。
- 代码可能在未来使用
在敏捷学校，我们说YAGNI ：你不会需要它。 是的， 未来可能会有用处，但今天我们还不能确定明天的需求是否能够以任何可靠的方式来预测。 否则就是傲慢，傲慢自大。 我们可以知道的明天是：我们希望我们的代码库容易修改，而未使用的代码会减损这个特性。
- 删除后，作者可能会感到不舒服
作者必须克服它。 我们都写了一些事情，结果不是很有用 – 能够指向所有正在使用的代码（因为未使用的代码已被删除）而不是代码体可以说更好一些方法，“那个在使用！”
拿起一些代码并找出意图是不够的，但是现在你必须弄清哪些部分没有被使用？
代码已经写好了，努力了
这也是没有必要的。 如果你不使用它，它（无定义）是无用的，无论它做了什么或花了多less努力。
代码可以在同步和真实环境中testing
如果没用，即使你有testing也没用。 如果代码是无用的，那么对它的testing也应该是没有用的（所以保留注释代码会造成不明确的地方 – 你保留testing吗？如果你有注释代码的客户代码，你是否也评论客户代码？ ）
如果组织良好（分组，分离包，松散耦合等），它不会干扰整体代码分析或重构
不是这样。 所有的工具（源代码控制，静态分析，文档提取器，编译器等）运行速度都会比较慢，因为它们必须处理更多的数据（而且这些数据中的一部分或多或less是噪声）。
另一方面，如果代码编排不好，则会导致静态分析，重构和其他任何问题。
你正在向你的工具input引入噪音，并希望他们正确地处理它。
如果你的静态分析工具计算一个评论/代码比例呢？ 你只是把它搞砸了，直到昨天（或者代码被评论时）。
最相关的所有代码块都会导致延迟了解维护和进一步开发的代码，这种延迟几乎总是花费很多。 问问你自己：如果你需要了解一个函数的实现，你还有什么需要看的？ 两行清晰的代码，或两行代码，另外二十六条不再是实际的评论？
代码可能在未来使用
如果是这样，你会发现它在你的团队的SCM的select。
如果你使用一个有能力的SCM，并依靠它来保持死代码（而不是混乱的源代码），你不仅应该看到谁删除了这个代码（提交作者），而且是什么原因（提交消息）以及其他随着它的变化（其余的差异）。
删除后，作者可能会感到不舒服
所以？
你（我假设）整个团队的开发人员都是为了制作你所知道的最好的软件，而不是“你不知道如何在不损害X的感觉的情况下做出最好的软件”。
这是编程的一部分，大部分编写的代码最终都会被丢弃。 例如，Joel Spolsky在某个时候说，对他的公司来说，大约有2％的书面代码是用于生产。
如果您将开发者的自我优先于代码库的质量，那么您将牺牲产品的质量，对于…究竟是什么？ 保持你的开发人员的不成熟？ 保护你的同事的不切实际的期望？
编辑：我已经看到一个有效的理由，在源代码中留下注释掉的代码，这是一个非常具体的情况：当代码是写在一个奇怪的/不直观的forms和干净的方式重写它不工作的一个非常微妙的原因。 只有在多次尝试纠正问题并每次尝试重新引入同样的缺陷之后，这也应该适用。 在这种情况下，您应该添加评论直观的代码作为注释，并解释为什么它不起作用（所以未来的开发人员不会再次尝试相同的更改）：
// note by <author>: the X parameter here should normally // be a reference: // void teleport(dinosaur& X); // but that would require that we raise another dinosaur and // kill it every twelve hours // as such, the parameter is passed by value void teleport(dinosaur X); - 恐惧 。 这使得团队担心得更多，产生更less。 当引入更多死代码时，恐惧的数量呈指数增长。 “我们不知道这个位是否被使用，所以我们不敢删除或者触摸它。”
-
彻底改变 。 如果系统中任何需要更改的东西也存在于死代码中，那么您是否改变了它？ 很难知道它是不是在某个地方使用，所以它总是一个风险。 而即使不会破坏任何东西，死代码是否会在这个变化之后被取回使用呢？
当处理彻底的更改时，开发人员还必须检查每个包含代码的地方，在死代码的情况下，这是多余的。 检查它们会花费更长的时间，因为很难validation它在任何地方都没有被使用。
- 心理负荷 。 每次你需要考虑是否使用了什么东西，或者你是否应该对死代码做些什么，这需要你的一些智力。
- 野鹅追逐 。 “我需要一个关于如何使用Foobar的例子，哦，它在代码库的这些地方，我会检查第一个命中，并找出UI中的位置，呃…找不到它。
- 膨胀的报告 （例如，多less行代码，类，例程，更改）。 歪曲项目的可见性以及决定代码库的哪些部分应该工作以及对未来项目的估计。
- 减弱了对代码库的信任 。 这可能会导致在冗余任务上花费更多的时间，并打破了使用代码库的stream程。 开发人员可能必须非常小心地检查他们使用的所有东西都会按照他们认为的方式工作。
如果您知道代码库的一部分没有被使用，那么这是非常有价值的，因为那么您可以删除它。 如果让它留在将来，可能很难或几乎不可能确定它实际上不被使用。 例如，一些以惊人的方式使用代码的东西： reflection，dynamic调用从string连接的例程，eval，框架魔术 。
但是，如果将来使用代码的可能性很高，那么在其他代码而不是版本控制系统中添加代码就更容易。 你可能不记得代码过了一段时间，所以很难从VCS的肠子里find代码。 但是我会让死代码很less存在，即使这样我也会将代码注释掉。
死代码污染你的代码
死代码降低了可理解性和可读性。
最好的代码总是被重用，如果你有死代码，它会降低重用性
我们是通过模块化的编码方式来驱动的，在这里我们devise与同行程序员交互的代码，而不是机器。 我们应该尽可能地让他/她理解我们的代码。 无论如何，机器会很好。
死或注释的代码就像虚假的痕迹，只是迷惑人，所以不惜一切代价避免它。
首先，你应该总是使用一个源代码pipe理工具来pipe理你的项目，因此删除未使用的代码是一个很好的做法，因为你总是可以回头使用源代码控制来获取代码。 对于我来说，删除未使用的代码的原因是只有知道代码的人不知道它，团队中的其他人才会遇到该代码，并试图弄清楚它在做什么以及它如何适应整个应用程序，经过这么多的努力后，会感到失望，代码根本不用:)
我认为你可以有两种情况： – 应用程序代码：如果它没有使用，也许它是没有经过testing和不知情的，也许你可以转移到“内部代码库” – API代码：如果你正在编写一个库然后恕我直言维持它的一个更好的select，但在你积极的开发过程中
我认为我们最好删除未使用的代码，如果已经删除了，我们可以在历史上再次看到svn / cvs，这样我就可以很容易地比较这两个代码而不牺牲性能。
