gpt4 book ai didi

version-control - 出于历史目的注释掉代码的替代方法

转载 作者:行者123 更新时间:2023-12-04 02:06:22 26 4
gpt4 key购买 nike

出于可查找性的原因,是否有人有使用已注释掉的代码 checkin 存储库的有效替代方法?

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

他的反对意见是,他 checkin 的一些注释掉的代码仍然说明了他将来想要修复的一些工作(在这个特定的点上,注释掉发生在 2 年前,但这不是重点)。他想把它保存在代码库中,这样他就可以很容易地找到它,即使它当前不能编译,它仍然在全局行中显示了解决它的正确方法。

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

我能想到的唯一选择是:

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

  • 有谁知道/使用任何替代品?我的两个选择听起来都比实际值(value)要多,但这可能会被我的推理所歪曲,即注释掉的代码无论如何都是毫无值(value)的。我不想走“嘿,如果你现在没有时间修复它,无论如何留在代码库中都不够重要”路线(但如果没有可行的替代方案,我会这样做)。

    对不起,标题太糟糕了,我想不出更好的了

    最佳答案

    分支在这里很有用。使用 SCM 的一种模式是为每个功能创建一个分支。当分支合并没有痛苦时,这很受欢迎 - 所有 SCM 都无法提供这种便利...... :-)

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

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

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

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

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

    关于version-control - 出于历史目的注释掉代码的替代方法,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2972907/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com