请教:修改代码的方法.(注释掉再加OR直接修改)

戎马

在维护现有400代码的过程中,总是会遇见修改某段逻辑的时候,我们这里的规则是把要修改的语句注释掉,加上TAG,然后在加一条新的语句,也加上TAG,这样,经过长期的维护之后,代码里的注释就会满天飞.无数的注释附在里面.

虽然说这样可以保留更改的记录,但是有时候又会觉得让程序,变得冗长,有时候,改掉的代码也没有了意义,不知道,各位有什么好的想法和做法.

roden

一般都是这样处理的,注释多说明BUG多,业务更改多

wildfish

注释太多也不好,注释太少也不好,仅仅标志修改的注释应该只能保持一段时间,太久了,就是代码垃圾.
最关键是程序的规范和需求的文档.
回想当年下载代码整理逻辑的日子就觉得超级恐怖....

戎马

嗯,对的,我们的程序是从82~83年就写好了,到现在,修改了无数遍,注释都已经到处都是,有些都是很早做的修改,有时候为了改个程序要翻无数页,看的眼睛都花掉.现在打开满程序就心烦.维护起来简直是要命,有时候看看程序头上的修改记录,都要翻到几千行以后.总的来说,我觉得这些注释掉的代码,会对程序的维护影响越来越大.

fairyboy

嘿嘿,我们着也差不多,一个400多行的代码,修改了20次标记,恐怖,最后,400多行中.200多行是注释的。

胖有型

所以以前我常向客户建议，修改的注释最好和程序说明的注释分行隔开，这样以后就可以自己写程序自动去掉修改的注释了。
整理程序的注释，可以参照数据清理的模式，隔一段时间就用程序自动整理一下程序的注释。

戎马

原帖由 胖有型 于 2007-12-13 17:01 发表
所以以前我常向客户建议，修改的注释最好和程序说明的注释分行隔开，这样以后就可以自己写程序自动去掉修改的注释了。
整理程序的注释，可以参照数据清理的模式，隔一段时间就用程序自动整理一下程序的注释。

楼上的可能没明白.比如,我们在修改一个语句的时候,不是直接修改,是先把原来一句注释掉,然后再加一句新的.比如下面的代码:

1. 
   
2. 
   
3. 1.01 C*                   MOVE      'Y'           AAA  
   
4. 1.01 C                     MOVE      'X'           AAA
   
5. 
   

复制代码

所以,如果修改的版本越来越多,那么注释掉的代码行就会很多.

胖有型

我的意思是这样的，比如：

C*这是一段关于程序流程的注释，说明为什么要这样赋值
C*                        MOVE      ' Y'         AAA
C                          MOVE     'X'          AAA

那么同样是注释行，这里就有两种注释，一种是用来说明程序流程的，一种是用来标识以前存在，现在注释掉的代码。
我们希望保留前一种注释，而不希望保留太多后一种注释。

如果在编写程序时按照一定的规范来区分这两种注释，那么我们就可以编写工具（也就是一组程序），通过运行这个自已写的工具，去自动清理源代码，把那种非程序流程类的注释（也就是修改类的注释）行直接删除掉，这样的程序看起来就很干净了。

这种源代码的清理可以类似于对数据清理一样，隔一段时间进行一次。（当然事先需要做好备份，磁带或硬盘）

就算不做清理，至少看程序的时候可以使用自己编写的程序工具去看那个相对干净一点的版本。

但是一定要定一个规范，用来区别需要去掉的注释，和需要保留的注释。

82年的程序，到现在有25年的历史，要是修改时的注释一直没有清理的话，的确是件很恐怖的事情，至少可以把5年以前的注释都清理掉了吧？

3楼说得我比较赞同，修改类的标签注释太多太少都不好，保留一段时间以内的就够了。（数据清理也是这样的原则）

[ 本帖最后由 胖有型 于 2007-12-14 18:04 编辑 ]

fairyboy

呵呵，有时候看自己改的程序,有注释也挺方便的.

wildfish

正常来说，一个程序如果因为业务不变更而不修改，那还是挺好的。
建议是十年的还是重新整理文档，流程修改，重新编制。
呵呵，难以想像一个业务十年了还没有很大的变化。尤其是岁数比俺小一些的程序。
再说了，现在Web的拓伸，对业务是影响最大的。从原本以自己为本位的业务慢慢的转变成以客户为本位的业务。所以还是应该适当的调整程序吧。程序维护到了一定的程度，维护的成本就远远高于重新编制带来的成本。