我应该删除未引用的代码吗？

我正在研究中等大小（10万行）的代码库，它们都是相对较新的代码（不到一年），并且具有良好的单元测试覆盖率。

我不断遇到的方法要么不再在任何地方使用，要么仅在仅测试特定方法的单元测试中引用。

如果确定不再需要此代码，是否应该删除它？

删除它的原因：

• 更少的代码，更少的错误
• 更少的代码更易于他人消化
• 它仍在源代码控制下

保留它的原因：

• 可以作为参考
• 有时可能有用
• 它可能被编写为“完善”类的功能

简而言之，您保留它的大多数理由都不重要。如果不使用该代码，则将其丢弃-可以从源代码管理中轻松获取保留该代码所涉及的任何好处。最多留下一条评论，指出要在哪个修订版中找到它。

简而言之，您越早切割代码，就不必越早浪费时间维护，编译和测试代码。这些优势大大超过了您概述的琐碎好处，无论如何，所有这些好处都可以从源代码控制中获得。

删除它的所有原因都是正确的。

保留它的原因：

• 可以作为参考
• 有时可能有用
• 它可能被编写为“完善”类的功能

所有这些保留它的原因将由源代码管理来管理。从实时代码中删除它，您将可以在需要时/在需要时对其进行检索。

未引用的代码与保持电池的电量相同，以防万一您需要一天使用它们进行割炬。

只要您使用某种版本控制，我都会说将其从实时代码中删除，并使用版本历史记录以防万一它有用。

我可以看到保留当前未使用的代码的唯一好理由是，如果它是独立模块的一部分：虽然目前可能不使用部分代码，但很可能它们将被使用。将来使用。

对于在不同项目中使用的库而言，尤其如此：您不想根据特定项目的需要而不断地向内扔代码：我发现这很耗时且容易出错。

我的方法是：（1）如果只使用一次，请仅保留您真正需要的东西；（2）如果您使用了两次，请在第二次使用时进行复制和改编；（3）如果您使用它两次以上，请用它制作一个定义明确，稳定的模块，然后根据需要使用此模块。

总结：我将丢弃所有未使用的代码，除非它是您这样设计的通用模块的一部分，并且您知道您将重复使用几次。

注意：当然，更干净的解决方案是为库创建一个单独的项目，并在项目之间添加依赖项。

通常，我会为此鞠躬。如果“不需要”，那么它只是在代码库，单元测试和程序集中占用空间。您可能最终需要它，但也可能最终需要完全重写它，因为从现在到需要类似它的东西之间，可能会发生很多变化。

但是，当您编写用于一般用途的实用程序或API时，情况会有所改变。就像您永远无法期望软件最终用户以您想要的方式与软件进行交互一样，您永远也不能期望代码的使用者希望完全按照您认为的方式使用代码。在这种情况下，只要您可以使用“这是一种与我的对象进行交互的有效方法”来证明方法的存在，那么它就应该加入其中，因为即使您不需要它，SOMEONE也会有很好的机会。

鉴于代码库不到一年的历史，它可能仍处于不断变化中（是吗？）-因此，在不久的将来可能需要重新使用某些比特的想法并不是没有道理的。

对于一开始很难正确处理并且似乎更有可能复活的位，我将使它们比“源代码控制”中的“活着”更多。人们不会知道/记住他们的存在-说“您可以在源代码控制中找到它”是假设您知道/记住它的存在！在这种情况下，请考虑弃用（使用“ assert（false）”显示顶部）或注释掉。

如果代码是琐碎且无趣的，那么我只是将其扔掉，以消除软件系统不必要的惯性。

对于有趣的代码尸体，我archive在版本控制系统中使用一个分支。

“可以用作参考”我不会倾向于同意保留未使用的代码是一个很好的理由。通常，只有一小部分未使用的代码实际上在演示一些有趣的事情。有多种方法来记录和存储有用但未使用的代码。

尽管版本控制将包含一个历史记录，如果您以后决定需要使用代码，可以轻松地使您还原特定功能，但是知道您需要查看版本控制历史记录以从谁知道以前的修订版可以找到xy或z。除非您对所要查找的内容有一个非常明确的想法，否则它会有些乏味，并且经常被忽略。

可以用注释说明该代码何时被删除以及为什么不将其简单地从代码中删除。但是，这通常被认为是不好的样式，如果以后不加注释，则未被使用和维护不正确的代码可能会引入各种错误，因此，与中期重构相比，此方法作为临时调试/测试步骤通常要好于留下生产代码的方法。

我最喜欢的存储已删除代码的方法（如果将来可能会有用的话）是制作包含所有各种有价值的已删除代码块的辅助参考文档。每个代码块都有一个简短的标记，标明了它的来源或其他需要记住的内容，例如何时删除代码或代码的最后修订版本。被删除但“潜在有用”的所有内容都集中在一个位置，易于搜索，但不需要持续不断地维护和测试（测试推迟到重新引入代码的任何地方）。

保留未使用方法的一个很好的理由是：它们可以在其他分支/标签上使用！

删除所有活动的分支和标记之前，请先对其进行探索。

如果使用版本控制系统，则不必担心将来的引用，因为您可以简单地查看该代码的历史记录并找到已删除的部分。如果不这样做，你认为这是一天使用，后来干脆让它呆在那里，但评论也有说明，解释为什么它的评论。

但是，如果您确定将来不会使用它，只需将其删除。我认为您提到的原因非常容易删除代码。

但是请在删除它之前，确保没有在任何地方使用它。Visual Studio具有一项称为“ 查找所有引用”的功能，该功能可搜索整个解决方案并查找对当前变量，方法，属性，类，接口等的任何引用。在删除部分代码之前，我始终确保没有任何引用。

我经常有发现一种看起来像它可以完全满足我需要的功能的经验，并且因为它已经投入生产很长时间了，所以相信它可以正常工作，只是发现它实际上并没有被使用。几年。未使用的代码不会得到维护，尽管它可能已经使用多年了，但其周围的API已经发生了足够的变化，以至于您无法信任它。

充其量，您最终会花费大量时间来确保它实际上仍然可以满足您的要求。在最坏的情况下，它似乎一直有效，直到您后来被一个讨厌的bug咬住，并花费更长的时间进行跟踪，因为您认为“经过生产测试”的代码可以工作，因此问题必须在新代码中的其他地方出现。以我的经验，仅自己编写一个新函数几乎总是更快。

如果您删除了它，但是很快就发现您确实需要它，那么它就在源代码管理中。如果直到很长时间才不需要它，而您又不记得它在源代码控制中，那么最好还是从头开始编写它。

没有什么比没有代码消耗更少的时间了。

如果您必须深入研究代码库，则需要一些时间来弄清楚该代码的用途，如果什么都不用，则需要更多时间。

好的-可以通过评论将其治愈，然后再次，每个人都将推理为什么未使用的代码仍然存在于代码库中，无论是否应将其删除。

如果什么都没有，没有人会浪费时间。

如果很难正确处理，则需要一个很好的文档，证明该代码存在，但是如果代码库经过一些迭代而演变，则如果重新激活它，则可能不再起作用。

删除未使用的代码-减少混乱，更好地理解。您的版本控制系统会注意。另外，如果您使用的东西比记事本还好，则您的环境将允许您使用旧的代码作为参考。

旧代码的冗长注释会分散注意力，并且使导航变得困难。

问候

请遵循以下简单算法：

1. 是否在SCM中备份？是=> 3。
2. 设置一个SCM。
3. 把东西扔掉。

您支持删除的所有观点都是有效的。

一旦拥有SCM来查找或恢复它，所有用于保持混乱的观点都是无效的。实际上，如果使用正确，您的SCM应该能够帮助您确定为什么在这里未使用该代码。

出于某种原因，它被称为“死代码”。让它死去，安息吧。

它将保留在源代码管理中；它不应保留在活动代码库中。

一个例外是，如果代码完成了设计，并且在您不使用代码时，您计划最终将代码公开，而其他人可能想要该基本功能。然后，只需设计测试以确保代码的这些部分可以正常工作，以模仿您建议他人如何使用这些代码部分即可。但是，如果您甚至正在考虑删除代码，但又不能提出保留该代码的充分理由，则应该删除它。未使用的代码使每个人的工作量更大（难以阅读代码；代码可能被破坏；需要维护的工作量更多，等等）。

以我的经验，删除未使用的代码也会适得其反。您可能会忘记拥有该代码，并且不会在历史记录中寻找它。或者，您甚至可能不知道有人实现了该代码，然后在以后将其删除。同样，您将不会在历史中寻找它...

无疑，拥有未使用的代码是一种难闻的气味。

更新：我只是注意到埃德·史陶布（Ed Staub）给出了非常相似的答案。