11

出于可查找性的原因，是否有人有有效的替代方法来使用签入存储库的注释掉代码？

我问的原因是因为我最近与一位开发人员讨论了签入被注释掉的代码。我的立场是，注释掉的代码永远不应该检查到我们的 VCS 中，因为它在技术上不是代码库的一部分，因此可以说是不值得它占用的字节的烦人的垃圾。

他的反驳是，他签入的一些注释掉的代码仍然说明了他希望在未来修复的一些工作（在这个特定的点上，注释掉发生在 2 年前，但这不是重点）。他想将它保存在代码库中以便他可以轻松找到它，即使它当前无法编译，它仍然在全局行中显示了解决它的正确方法。

最后他同意了，有点，注释掉的代码不属于。但是，当我们考虑他的可能替代方案时，我们想出了很短的时间。

我能想到的唯一选择是：

  • Wiki：只需将其粘贴到 Wiki 上的某个位置。这样做的缺点是它会与其他非代码相关的 wiki 内容混合在一起，这可能会使搜索变得困难。
  • 索引所有 VCS 修订：这对我来说主要是理论上的，但是是否有系统可以使代码库及其整个历史可搜索？

有谁知道/使用任何替代品？我的两种选择听起来都比实际价值要多，但这可能与我的推理有关，即注释掉的代码无论如何都是一文不值的。我不想走“嘿，如果你现在没有时间修复它，那么留在代码库中并不重要”路线（但如果没有可行的替代方案，我会这样做）。

对不起这个可怕的标题，我想不出一个更好的

4

7 回答 7

4

分支在这里很有用。使用 SCM 的一种模型是为每个功能创建一个分支。当分支合并无痛时，这很受欢迎 - 所有 SCM 都无法轻松实现...... :-)

这个想法是，您处理的每个功能都有一个专用的分支，并且完全在该分支内工作。当功能完成、工作、测试、记录并赢得两枚奥运金牌等之后，该分支将合并到主干中。或者，如果该功能从未完成或放弃等，分支将无限期保持打开状态。但代码仍然可见，准备好在某天被某人拾取。

这是存储“正在进行的工作”的好方法 - 因为代码是分支的，您可以自由地检查暂定代码。它不需要被注释掉，因为正在进行的工作更改仅在那个孤立的分支中，甚至不需要编译，因为这些分支通常不会迁移到持续集成中，直到它们达到成熟水平。

与注释掉的代码不同，这些暂定的代码更改是可见和可搜索的，适用于代码分析工具、重构等。

在某些环境中，功能及其分支也可能具有关联的变更单或问题跟踪 ID。这确保了重大更改不会丢失，并提供了一种对各种功能进行优先级排序和组织的方法，从修复 showstoppers 到尝试以不同的方式实现可能永远不会出现的东西。

至于搜索，有些单片机有搜索前端。例如，SVN 有 SVNSearch - http://sourceforge.net/projects/svn-search/。还有svnquery，既可以搜索历史，也可以搜索头部。

于 2010-06-04T09:47:09.760 回答
3

我知道该代码已不再使用，但它包含未来可能会感兴趣的想法。

我将存储在控制版本系统中，但我会将其保存在单独的文件夹中，例如removed-code-to-review-later. 然后，我会在审查时将其删除。

于 2010-06-04T09:44:08.950 回答
2

他签入的一些注释掉的代码仍然说明了他希望在未来修复的一些工作

然后他应该在你的 bugtracker 中打开一个低优先级的票，描述他想要修复的内容，并将当前注释掉的代码添加为该票的注释。现在他可以把这张票分配给自己，其他人都不会被它打扰。

注释掉的代码就像任何其他注释一样：如果没有得到适当的维护，它往往会失去与代码的一致性，从而失去它的实用性。

于 2010-06-04T10:14:51.910 回答
1

根据我的经验，签入注释掉的代码的最大原因是开发人员非常讨厌打字，以至于他们宁愿将未使用的代码放在手边，以防将来需要键入类似的代码片段。

你的情况有点不同，但我仍然说“使用它或失去它”。如果注释掉的解决方案修复了一些重要的问题，那么这将是完成它的一个很好的动机。很容易花更多的时间来解释为什么某些事情不太正确以及“我们从未有时间修复它”，而不是花更多时间来解决它。

最后一点是基于这样的断言，即开发人员的时间是非线性的，并且开始做一些你有动力去做的事情比每次都“为项目 Y 预订 X 小时”带来更多的价值。

有些版本控制系统非常擅长创建和合并分支。Mercurial、git 等都可以做到这一点。即使您不使用其中之一作为您的主要 VCS，也没有什么可以阻止您的同事创建一个本地存储库来保存他的实验。

于 2010-06-04T09:56:27.780 回答
1

在某些情况下，最好记录一些复杂/独特问题的解决方案，以供参考。我认为它不应该属于代码。恕我直言，我认为某种维基是​​最好的选择。

如果您在过去 2 年内没有使用过该代码，您会使用它吗？如果您这样做了，您是否还应该使用 2 年前的代码？如果您需要再次将该逻辑添加到代码中，最好从头开始编写它，因为很可能在这段时间内事情会发生变化，您会学到很多东西，会为您提供额外的资源等

于 2010-06-04T10:01:08.567 回答
1

听起来你的朋友应该创建一个分支并在那里尝试他的“改进”。您将能够轻松地在此改进分支和当前源之间进行区分，以清楚地表示他打算进行的更改。

于 2010-06-04T09:39:31.970 回答
0

您的声明“即使它当前无法编译，它仍然在全局行中显示了解决它的正确方法。”

<>

您的陈述“无论如何，我注释掉代码的推理毫无价值。”

我不认为留下评论有什么害处，因为它们通常会为未来的开发人员提供有关最初开发人员意图是什么以及现有代码中的任何当前限制的见解。存储在不同的系统中会增加它们丢失给未来开发人员的机会。字节很便宜，重新创建另一个开发人员意图所需的时间是 $$$。

于 2010-06-04T17:27:28.110 回答