我不断遇到两种方法不再在任何地方使用或仅在仅测试特定方法的单元测试中引用。
如果确定不再需要此代码，是否应该删除此代码？
原因删除它：
更少的代码，更少的错误
更少的代码更易于其他人消化
它仍在源代码控制之下
保留它的原因：
可以用作参考
它有时可能有用
它可能被编写为“舍入”功能类
#1 楼
简而言之，您保留它的大多数理由都不重要。如果不使用该代码，则将其丢弃-保留该代码所涉及的任何好处都可以从源代码管理中轻松获得。最多留下一条评论，指出要在哪个修订版中找到它。它。这些优势大大超过了您概述的琐碎好处，无论如何，所有这些好处都可以从源代码控制中获得。评论
我同意删除它，但是在某些情况下我因为某些人通过反射使用“未使用”的代码而破坏了某些内容。因此，无论如何都应该小心。
–猎鹰
2011年8月23日在9:52
@Falcon，这是在人们开始使用它或发现需要将其公开之前尽快删除它的一个很好的理由。
– StuperUser
2011年8月23日10:00
@Falcon：这是OP的声明，即代码未使用。
– DeadMG
11年8月23日在10:02
@StuperUser：我完全同意。但是应该小心并为意外做好准备。
–猎鹰
11年8月23日在10:09
如果删除它，并且您的单元测试和回归测试通过了，但是该产品在领域中破裂，则为设置某种类型的代码覆盖率工具提供了有力的依据。
–安德鲁（Andrew T Finnell）
11年8月23日在12:01
#2 楼
卸下它的所有原因都得到保留。保留它的原因：
可用作参考
它有时可能有用
/>可能是为了使类的功能“全面”而写的。
所有保留这些类的原因将由源代码管理来管理。从实时代码中删除它，您将可以在需要时/在需要时对其进行检索。
评论
是的，未引用的代码不应保留在实时代码中。
– xdazz
11年8月23日在16:04
在我看来，您也可以通过简单地注释掉大块内容来获得这些好处。
–史蒂夫·贝内特（Steve Bennett）
2012年1月4日，0：56
@SteveBennett确实，但是您误解了此答案的重点。我列出了对其进行评论的好处，关键是您将从源代码管理中获得所有这些以及更多的好处（您将在其他答案中看到）。
– StuperUser
2012年1月4日10:03
我当然不反对VCS。 ：）（不过，我确实注意到，一旦从当前版本中删除了内容，它与其他方法相比就不那么可见了，例如将其存储在未引用的文本文件，Wiki，注释等中。）
–史蒂夫·贝内特（Steve Bennett）
2012年1月5日7:49
@Steve Bennet-在文件的当前版本中，它的“可见性”可能不及注释，但检查单个文件的VCS历史记录却微不足道，我想说比txt-file / wiki / etc容易得多。 ..方法。
– Zach Lysobey
2014年11月7日16:06
#3 楼
未引用的代码与保持电池电量一样，有点平整，以防万一您一天需要用完它们。在实时代码中说出垃圾，并使用版本历史记录，以防万一它有用。
评论
为了使您的类比稍有改善，这就像是将快要用完的电池贴在遥控器上，而不是放在储藏室中标有“用过但未用尽的电池”的新电池旁边的盒子里。
–斯科特·惠特洛克
11年8月23日在15:01
加1可带来更好的改善！
–尼古拉斯·史密斯
2011年8月23日15:52
#4 楼
我看到保留当前未使用的代码的唯一好理由是，如果它是自包含模块的一部分：虽然目前可能不使用部分代码，但很可能它们将被使用。对于在不同项目中使用的库来说尤其如此：根据特定的需求，您不希望不断地向内扔代码。项目：我发现这很耗时且容易出错。
我的方法是：（1）如果只使用一次，则仅保留您真正需要的东西； （2）如果您使用了两次，请在第二次使用时进行复制和改编； （3）如果您使用它两次以上，请从中制作一个定义良好，稳定的模块，然后根据需要使用此模块。
总结：除非将其丢弃，否则我将丢弃所有未使用的代码是这样设计的通用模块的一部分，并且您知道自己将重复使用多次。
注意：当然，更干净的解决方案是创建一个单独的项目库，并在项目之间添加依赖项。
评论
举一个例子，我有一些库例程可以读取和写入字节数组中各种大小的有符号和无符号数据类型。根据当前代码所需要的内容，为所有数据类型设置一组这样的例程似乎比存在一些例程或不存在某些例程更为清洁。
–超级猫
2012年10月8日23:40
#5 楼
通常，我会为此鞠躬。如果“不需要”，那么它只是在代码库，单元测试和程序集中占用空间。您可能最终需要它，但也可能最终需要完全重写它，因为从现在到当您需要类似的东西时，很多东西都可以改变。但是，当您使用它时，情况会有所改变。重写用于一般用途的实用程序或API。就像您永远不能期望软件最终用户以您想要的方式与软件进行交互一样，您永远也不能期望代码的使用者希望完全按照您认为的方式使用代码。在这种情况下，只要您可以使用“这是一种与我的对象进行交互的有效方法”来证明方法的存在是合理的，那么它就应该加入进来，因为即使您不需要它，SOMEONE也会很有可能。
#6 楼
鉴于代码库还不到一年的历史，它可能仍处于不断变化中（是吗？）-因此，在不久的将来可能需要重新使用某些比特的想法并不是不合理的。对于那些一开始很难正确处理并且似乎更有可能复活的位，我将使它们比“源代码控制”更“活”。人们不会知道/记住他们的存在-说“您可以在源代码控制中找到它”是假设您知道/记住它的存在！在这种情况下，请考虑弃用（带有“ assert（false）”显示顶部）或注释掉。
评论
+1表示“您可以在源代码管理中找到它”，假设您知道/记住它已经存在！ -有时由于种种原因，我几乎没想到对代码有所帮助。
–史蒂文
11年8月23日在15:10
#7 楼
如果代码琐碎又无趣，那么我就把它扔掉，以消除软件系统不必要的惯性。对于有趣的代码尸体，我在版本控制系统中使用了
archive分支。 >#8 楼
“可以用作参考”我不会倾向于同意将其保留为未使用的代码。通常，只有一小部分未使用的代码实际上在演示一些有趣的事情。有多种方法来记录和存储有用但未使用的代码。尽管版本控制将包含一个历史记录，如果您以后决定需要代码，可以轻松地使您还原特定功能，因为您知道需要查看版本控制历史记录以查找xy或z谁知道以前的修订可能有点乏味，并且除非您有一个非常具体的想法，否则通常会被忽略。
可以注释掉该代码，并附带注释，说明何时删除该代码以及为什么不将其从代码中简单删除。但是，这通常被认为是不好的样式，如果以后不加注释，则未被使用和维护不当的代码可能会引入各种错误，因此，与中期重构相比，此方法作为临时调试/测试步骤通常要好于留下生产代码的一种方法。
我最喜欢的存储已删除代码的方法（如果将来似乎很有用）是制作包含所有各种有价值的已删除代码块的辅助参考文档。 。每个代码块都有一个简短的标记，说明了它的来源或其他需要记住的内容，例如何时删除代码或代码的最后修订版本。已删除但“可能有用”的所有内容都集中在一个位置，可以轻松搜索，但不需要持续不断地维护和测试（将测试推迟到重新引入代码的任何位置）。
#9 楼
保留未使用方法的一个很好的理由是：它们可以在其他分支/标签上使用！在删除它们之前，请探索所有活动的分支和标签。
评论
这对我来说没有任何意义：如果未在此分支中使用它，请将其从该分支中删除。如果另一个分支使用它，它将留在那里。
–sleske
2013年9月26日14:08在
#10 楼
如果使用版本控制系统，则不必担心将来的引用，因为您可以简单地查看该代码的历史记录并找到已删除的部分。如果您不这样做，并且认为有朝一日可以使用它，那么就让它停留在那儿，然后在注释中加上说明原因的注释即可。但是，如果您确定会赢的话将来不再使用它，只需将其删除即可。我认为您提到的原因很容易删除代码。
但是请在删除代码之前，确保不要在任何地方使用它。 Visual Studio具有一项称为“查找所有引用”的功能，该功能可搜索整个解决方案并查找对当前变量，方法，属性，类，接口等的任何引用。在删除部分代码之前，我始终确保没有任何引用。
#11 楼
我经常有发现一种看起来像它可以完全满足我需要的功能的经验，并且因为它已经投入生产很长时间了，所以我相信它可以正常工作，只是发现它实际上并没有被使用过。几年。未使用的代码不会得到维护，尽管它可能已经使用多年了，但其周围的API已经发生了足够的变化，以至于您无法信任它。最好的情况是，最终花很多时间来确保它实际上仍然可以满足您的要求。在最坏的情况下，它似乎一直有效，直到您后来被一个讨厌的bug咬伤，并花了更长的时间追踪它，因为您认为“经过生产测试”的代码有效，因此问题必须在新代码中的其他地方出现。以我的经验，仅自己编写一个新函数几乎总是更快。
如果删除它，但是很快就发现自己确实需要它，它就在源代码控制中。如果直到很长时间才不需要它，而您又不记得它在源代码控制中，那么最好还是从头开始编写它。
#12 楼
没有什么比没有代码消耗更少的时间了。如果您必须深入研究代码库，则需要一些时间来弄清楚该代码的用途，如果不使用它，则需要更多时间。
好吧-可以通过评论加以补救，但是接下来，每个人都将推理为什么未使用的代码仍然存在于代码库中，无论是否应将其删除。
如果什么都没有，没有人会浪费时间。
如果很难正确使用此代码，则需要一个很好的文档，证明该代码存在，但是如果代码库经过某些迭代而演变，则如果重新激活它，可能将不再起作用。
#13 楼
删除未使用的代码-减少混乱，更好地理解。您的版本控制系统会很注意。此外，如果您使用的东西比记事本还好，那么您的环境将允许您使用较旧的代码作为参考。并导致导航困难。
注意事项
#14 楼
请遵循以下简单算法：是否将其备份在SCM中？如果是，请跳至3。
设置SCM。
将其扔掉。
您提出的所有支持删除的观点都是有效的。
一旦拥有SCM来查找或恢复它，所有支持保持混乱的观点都是无效的。实际上，如果使用得当，您的SCM应该能够帮助您确定为什么在这里未使用该代码。
出于某种原因，它被称为“无效代码”。让它死亡并安息吧。
#15 楼
它将保持在源代码控制中；它不应保留在活动代码库中。一个例外是，如果代码完成了设计，并且在您不使用代码时，则计划最终将代码公开，其他人可能希望基本功能。然后，只需进行设计测试，以确保代码的这些部分可以正常工作，以模仿您建议他人如何使用代码的这些部分。但是，如果您甚至正在考虑删除该代码并且无法提出保留该代码的充分理由，则应该删除它。未使用的代码使每个人的工作更多（难以阅读代码；代码可能会被破坏；需要维护的工作等等）
#16 楼
以我的经验，删除未使用的代码也会适得其反。您可能会忘记拥有该代码，并且不会在历史记录中寻找它。否则，您甚至可能不知道有人实现了该代码，然后在以后将其删除。再一次，您将不会在历史中寻找它。毫无疑问，拥有未使用的代码是一种难闻的气味。
更新：我只是注意到Ed Staub给了一个非常相似的答案。
评论
“更少的代码，更少的错误”-如果确实从未使用过它们，则不太可能导致错误@Morawski但是，如果保留它，则将使用一天。而且由于尚未维护，因此会包含错误，然后会出现错误。
我通常会注释掉它以及依赖它的测试，然后留下带有日期的“ TODO”注释。一旦一年不使用，我就将其卡住。其他人建议立即将其删除，但是我发现很难做到这一点，特别是如果看起来代码曾经有用的话。
@Job如果我遇到注释掉的代码，它将被删除。没有理由。注释掉的代码只会大喊“我不信任我们的源代码控制系统”。给我。
@Kristof Provost，您怎么会知道有用的代码曾经存在于源文件A中（如果不再存在）？当然，您始终可以检查文件的历史记录，但是您经常想一下自己：“嗯...我需要在此处更改/实现功能。或者我需要测试5年的工作原理之前是QUICKLY。我想知道是否有人已经实施了它，然后将其删除了……让我检查一下历史”。我不是在提倡乱七八糟的废话，但是在某些情况下，您可能不会在生产中使用代码，但是有时需要/可能需要它来进行调试等。