是否有人有一个有效的替代方法，使用已注册的代码进入存储库以查找可查找性？
我问的原因是因为我最近与其他开发人员讨论过检查已注释掉的代码。我的立场是，注释掉的代码永远不应该被检查到我们的VCS中，因为它在技术上不是代码库的一部分，因此令人讨厌的瑕疵不值得它占用的字节，可以这么说。
他的反对意见是，他检查过的一些已注释的代码仍然说明了他希望将来修复的一些工作（在这一特定点上，评论发生在2年前，但这是除了这一点）。他希望将它保留在代码库中，以便他可以轻松找到它，即使它目前无法编译，它仍然在全局范围内显示正确的解决方法。
最后，他同意了，注释掉的代码不属于。但是当我们想到他可能的替代品时，我们的确很短。
我能想到的唯一选择是：
有没有人知道/使用任何替代品？我的两个选项听起来都比实际值得多，但是我的推理可能会因为注释掉的代码毫无价值而有所偏差。我讨厌不得不去“嘿，如果你现在没有时间来解决这个问题，那么无论如何都要留在代码库中”并不重要“（但如果没有可行的替代方案，我会这样做）。
对不起这个可怕的头衔，我无法想出一个更好的头衔
答案 0 :(得分：4)
分支在这里很有用。使用SCM的一种模型是为每个特征创建一个分支。当分支合并无痛时，这很受欢迎 - 所有SCM都无法轻松实现......： - ）
我们的想法是，您处理的每个功能都有一个专用分支，并且完全在该分支内完成。当功能完成，工作，测试，记录，并赢得两个奥运金牌等。然后分支合并到主干。或者，如果功能从未完成或放弃等，分支将无限期保持打开状态。但代码仍然可见，有一天可以被某人接收。
这是存储“正在进行的工作”的好方法 - 因为代码是分支的，您可以自由地检查暂定代码。它不需要被注释掉，因为正在进行的工作只是在那个孤立的分支中，甚至不需要编译，因为这些分支通常不会迁移到持续集成，直到它们达到成熟度。
与注释掉的代码不同，这些暂时的代码更改是可见的和可搜索的，可用于代码分析工具，重构等。
在某些环境中，功能及其分支也可能具有关联的更改票证或问题跟踪ID。这确保了重大变化不会丢失，并提供了一种优先排序和组织各种功能的方法，从showstoppers的修复到实现某些可能永远不会看到光明的不同方式的实验。
对于搜索，一些SCM有一个搜索前端。例如，SVN有SVNSearch - http://sourceforge.net/projects/svn-search/。还有svnquery，它既可以搜索历史也可以搜索。
答案 1 :(得分：3)
我知道代码已不再使用，但它包含的想法可能对未来感兴趣。
我将存储在控件版本系统中，但我会将其保存在单独的文件夹中，例如removed-code-to-review-later。然后，当我查看它时，我会删除它。
答案 2 :(得分：2)
他检查过的一些注释掉的代码仍然说明了他希望将来修复的一些工作
然后他应该在你的bugtracker中打开一个低优先级的票，描述他想要修复的内容，并将当前注释掉的代码添加为对该票证的评论。现在他可以将这张票分配给自己，其他任何人都不会被它打扰。
注释掉的代码就像任何其他注释一样：如果没有正确维护，它往往会失去与代码的一致性，从而失去它的实用性。
答案 3 :(得分：1)
听起来你的朋友应该创建一个分支并在那里尝试他的“改进”。您可以轻松地在此改进分支和当前源之间进行区分，以清楚地表示他想要的更改。
答案 4 :(得分：1)
根据我的经验，检查注释掉的代码的最大原因是开发人员讨厌打字太多，以至于他们宁愿保留未使用的代码，以防万一他们将来需要输入类似的代码片段。 / p>
你的情况有点不同，但我仍然说“使用它或丢失它”。如果注释掉的解决方案修复了一些重要的东西，那么这将是完成它的一个好动机。很容易花更多的时间来解释为什么某些东西不太正确以及“我们从来没有给它时间来解决它”而不是它需要做的事情。
最后一点是基于开发者时间是非线性的断言，并且开始使用你有动力去做的事情比每次“预订到Y项目的X小时”提供更多的价值。
有一些版本控制系统非常擅长创建和合并分支。 Mercurial，git等都能够做到这一点。即使你没有使用其中一个作为你的主要VCS，也没有什么可以阻止你的同事创建一个本地存储库来保持他的实验。
答案 5 :(得分：1)
在某些情况下，为了参考目的，记录一些复杂/独特问题的解决方案是个好主意。我不认为它应该属于代码。恕我直言，我认为某种维基是最好的选择。
如果你在过去两年没有使用过该代码，你会使用它吗？如果你这样做，你还应该使用2年的代码吗？如果您需要再次将该逻辑添加到代码中，最好从头开始编写，因为很可能在这段时间内事情会发生变化，您会学到很多东西，可以为您提供额外的资源，等等
答案 6 :(得分：0)
你的陈述“即使它目前不会编译，它仍然在全球范围内显示解决它的正确方法。”
＆LT;＆GT;
您的陈述“我的理由是注释掉代码无论如何都是毫无价值的。”
我没有看到留下评论的危害，因为它们通常会为未来的开发人员提供有关原始开发人员意图的信息，以及现有代码中的任何当前限制。存储在不同的系统中会增加他们失去未来开发人员的机会。字节很便宜，重新创建另一个开发人员意图所需的时间是$$$。