Clear Code，关于注释代码与信任版本控制之间的异议

swxlion

关于漂亮的、干净的代码，已经有一些事项为大家所公认。而本人对其中的一项一直持有异议，希望能和大家讨论一下。

“不要在源文件中留下已经删除的代码，哪怕你标注了。” -- 原话。
原始理由 -- “如果你使用了版本控制，那么你就可以轻松地找回前一个版本的代码。如果别人大费周折地读了你的代码,却发现是要删除的代码，这实在太恨人了”，“影响阅读”，……

而我的亲身经历，则对该条款提出了明确彻底的异议！

经历1：
原来项目的版本控制使用的是CVS，后面转移到了SVN。
当我需要查找以前版本的代码的时候，很无奈的发现，以前的代码在CVS中，远在SVN的记录之前。而很可惜的是，因为时间和空间的关系，CVS，已经被“干掉”了。

经历2：
当项目新的主板本开始开发的话，往往会建立一个全新的分支，或者一个全新的trunk。
然后将以后的代码Check in，然后再在此基础上进行新版本的开发。而这个时候，以前版本的相关文件，在Check in到新trunk之前的历史信息，已经全部丢失！
或许有人说，可以去老的本版里面找。可是，万一项目很大，对老的版本，或分支没有访问权限，而且根据相关的保密措施，项目的管理员拒绝给你老版本对应代码的权限呢？（因为可能代码是同一各类的，但在新老版本中，却从属于不同的模块。）

经历3：
Merge。
很多公司都会为新的feature，或fix defect而开辟新的分支，而当分支合并时原始分支的历史版本，可能将会丢失。

经历4：
根据重构的需要，有些模块需要搬迁到新的文件中，有些文件需要新命名/重名名。
而在有些版本控制工具中，如SVN，重命名一个文件，它是当作删除然后添加过来处理的。这样一来，新的文件将会有新的历史，而原来的历史，已随老的文件烟消云散。
也许，从版本控制中还能找回被删除的老的文件。但如果作为一个新接触的员工，对于将重命名分解为删除和添加的操作而言，谁又知道以前被删除的文件是哪一个？时间长乐，老员工也记不住啊！

总结：
对于以后有影响的，比如修改参考，或者enhancement性能比对的代码，注释，但不要删除。除非确定以后真的不再需要。因为，版本控制工具，其实并不能满足我们所想象的需求。

（因找不到合适的板块，故在此发贴。如有不适，请斑竹移动之。）

swxlion

我一朋友看了这片贴子后，对我说，他们公司要求将所有注释掉的代码全部保留，不能删除！原因很简单，版本控制或许是可以找到（前面四点之外的情况下），但问题是，太难找了。

以他们公司为例，他们现在做的产品，revision已经达到7000多了。7千多个revision虽然不是每个文件度有这么多，但一个文件只要不是新文件，有个上百个revision算是很正常。这么多revision你怎么去找？

再以我们公司为例。我们现在做的9.0，光9.0就已经也有7000多的revision了，这么多revision你怎么去找
然后再加上第1版、第2版、第3版、第4版、第5版、第6版、第7版、第8版，以及上千个分支，近20年的代码，累计revision轻松上10万。10万个revision，你怎么去找？？

[ 本帖最后由 swxlion 于 2009-1-1 13:17 编辑 ]