不知道 mod by *** on 20050814 这样的注释有什么意思？

Edengundam

原帖由 快乐的土豆 于 2007-8-6 12:28 发表
有作用啊,文档化的时候用得上的--并不是所有的时候你都通过cvs这类工具去看源代码来了解当前的代码状态.
在一些开源项目的用户手册上还能看到todo list呢--其实就是通过源代码用工具倒出来的.

阅读开源代码, 我见过某些标记, 一般表示该块代码实现不是很完善或可能存在bug, 但是该代码确实主分支的代码. todo list是导出的??
我觉得很多变更是提交时候的comment生成的^^

flw

原帖由 Edengundam 于 2007-8-6 12:28 发表

我们comment用来写摘要的

有时候修改算法时候, 注释就得放在函数头, 文件头的位置了...

ID那个是多个版本之间修改时候, 防止某些人看不到history变更时候(我看不到某些版本的历史 ...

嗯，这个就见仁见智了，毕竟你说的这些 comment 是直接作用于代码本身的，它本身就是有用的信息，而不是间接有用的信息。

Edengundam

原帖由 flw 于 2007-8-6 12:32 发表

嗯，这个就见仁见智了，毕竟你说的这些 comment 是直接作用于代码本身的，它本身就是有用的信息，而不是间接有用的信息。

小改动不用, 不过我们有时候改语法树之类, 就得留在代码附近的注释里面. comment大都是本次修改的摘要信息.

flw

很奇怪啊，快乐的土豆你为什么频频删去你的回复呢？
已经删掉三个了。

yg

当有多个人开发和维护多个项目的时候，清楚的标注还是很有好出的。我们更多的碰到的情况是，要提交的时候发现某个相关的文件不知被谁在n久以前改了一下，如果全部测试都结束了，那就麻烦大了。

shmilylxx

没想我的回复版主还专门帖上来评判一番，呵呵。

这种注释，偶是吃了大苦头的。

flw

我更加倾向与一种这样的管理方式：
把和代码有关的东西，就地弄清楚。
该写的注释，写上。
为什么改动，是因为有了新的需求还是发现了 bug，如果这段代码很复杂，那么它的结构、原理都写清楚。
这样才算本次修改任务是完整彻底地做完了。
而不要跟影视明星似的留下一个签名，让人家去找你——万一你离职了怎么办？
可以说，项目经理允许这样的现象发生就是他的失职！
从一定程度上说，把事情和人分开反映了一个团队的靠谱程度。

zllfdd

原帖由 flw 于 2007-8-6 11:58 发表
我一向是极力反对的——理由很简单，随便哪个版本控制系统都可以支持，莫非这个公司从来不用版本控制系统？
比如 cvs ann svn ann 就可以看每一行代码的最终修改者。

更可笑的是有很多公司居然把这一条写入 ...

也许好多公司都没有，我呆这的两个公司都没有，也许是公司太小，也许不是专门的软件公司。
如果一定说有的话，那是手工的。

flw

原帖由 zllfdd 于 2007-8-6 12:49 发表

也许好多公司都没有，我呆这的两个公司都没有，也许是公司太小，也许不是专门的软件公司。
如果一定说有的话，那是手工的。

你可以建议你们公司试着用一下，
能够提高工作效率的事何乐而不为呢？
你的机器上是不是经常有很多备份？
比如 src-20070806.tgz
src-for-xxx.tgz
这样的东西呢？

shmilylxx

策远了，就策到代码风格和项目管理方面来了
其实对于小公司，过高的要求肯定不现实，不过，还是可以有些基本要求的，
比如：
1，使用CVS或者其他工具管理源码，有版本控制之后，日后的维护性和团队合作也方便很多，至少不用两个人围着用比较工具一行一行合并代码吧。
2，每个函数之前，一定要表明函数功能和概要逻辑！
   原因就不说了，维护项目多了的兄弟肯定心有感触。