关于代码的适度冗余

zhangsuozhu

楼主可能是看了我的贴子才发此文的。也怪我没说清楚当时的情况。

当逻辑很复杂时，一个变量或数据结构要跨越许多函数，甚至好多文件时，当另一个的开发人员接手维护时，也许接手者也没搞清代码的整个流程，只是看到了一部分，所以他对传过来的变量可能会做一些操作，比如清零，以保证变量的正确性。所以可能产生部分冗余的代码，这是可理解的。不过话又说回来了。如果传来的变量目前的状态都不知道，就盲目操作，也很危险，除非确定知道变量里的原来的内容可以被替换。

但这个例子不适合我发的那篇帖子。

1、变量是一个函数里的局部变量。大家都知道函数不应超过二屏的，也就是说，函数要精简，并只实现一个功能。
所以函数里的变量，可以初始化也可以不初始化。主要看编程者的喜好。

1. char buf[xxx] = {0};

复制代码

无可厚非，当然也可以不初始化。因为在一个短小的函数里，我们完全可以看到变量的状态。

2、下面的就是无用的操作了。
memse后是一个 sprintf.
因为sprintf函数会在buf里的字符串结尾自动置'\0'的。所以memset完全没必要。
有这种安全意识还不如把sprintf 改为snprintf更为重要。

更可气的是我看到sql_query 的原型是 int sql_query(cosnst char *format, ...)
那么这个buf 更是没有必要了。
而且整个函数一个有三四个sql查询。而函数的编写者每次都。
mem 然后 sprintf 然后sql_query.

所以我一气之下贴了出来。

幻の上帝

举个例子? 比如什么语言的什么机制支持你说的这种契约？ 能给例子最好,谢谢
donotblock 发表于 2010-11-19 20:44

比较明显就是原本可能进入C++0x的concept，可惜被砍了。
按我的理解，契约并不见得是具体的语言特性，也并不一定局限在实现的某一层次上，只要是通过语言能够表达的内容进行限制性语义（尤其是人和人之间的）的传递就可以算是契约。纯虚函数乃至静态类型检查都可以算是体现了一定的契约关系——编译器可以提醒撰写者写出一般意义上具有较合理语义的代码，而重用代码者则应该容易理解在这里使用这个特性的意图（即使可能产生误用，借助编译器的验证，也比手动根据代码中冗余信息的暗示除虫要方便——尽管实际上的冗余信息可能会更直白一些，但若既然如此为什么不考虑写成注释呢）——这是不同使用者通过对语言的一致理解实现的契约。而库也可以代替语言的角色，实现其中的一部分，例如assert。

gvim

原来还有出处啊，乱七八糟看了半天原帖，我个人觉得没那么复杂吧这个问题

冗余，是去掉之后仍然可以和非冗余代码一样正常工作，表现一样的业务性。如果某段代码去掉之后由于人为原因造成和非冗余代码不一样的业务性，那我认为就不是冗余。
一般的软件系统，冗余我觉得没太多必要。把操作需要的前置条件写在接口定义，或者调用上下文，或者注释在函数头部，或者用适当的标识号重点突出,把操作条件明显话可以避免很大部分冗余。
相信大家都有读过man手册和代码，数据结构里面的上锁条件，函数的上锁条件等等，写在声明后面不就完了？什么成员数据操作的时候需要什么锁；调用函数时如果有特别需要注意的，函数的头上或函数的man 手册会说明调用时需要什么锁条件,比如是否caller上锁，caller是否必须持有其它什么锁，调用完成后callee是否释放锁。。。

要我来做牛牛说的第一个事情，我会这样做：

1. ...
   
2. ...
   
3. ...
   
4. static int arr[XXX]={0};
   
5. ...
   
6. ...
   
7. ...
   
8. /*
   
9. * NOTE: arr在for操作之前需全部为0，该工作由callee负责完成       // （或caller完成）
   
10. */
    
11. static int somefunction(void)
    
12. {
    
13.     ...
    
14.     ...
    
15. 
    
16.     // 如果是callee满足条件，是必须的代码；如果是caller满足条件，就是不必要的冗余代码。
    
17.     memset(arr, 0, sizeof(arr));
    
18.     /* NOTE: 以下代码要求arr数组的成员必须都是0 */
    
19.     for (i=0;i<XXX;++i) {
    
20.         ...
    
21.     }
    
22.     ...
    
23.     ...
    
24. }
    
25. ...
    
26. ...

复制代码

另外，看到原帖后面说传NULL什么的之后的一系列东东，我认为选择是否进行合法性检查是函数自己的事情，可以做也可以不做完全相信caller，可以进行合法性判定也可以进行有效性判定，当然给系统带来负载:不判定(=0)<合法性<有效性。

不看函数接口定义，不看函数头上的注释说明，不按规矩调用的，属于项目管理里面处理的事，抓住没有任何辩解，扣工资让他记住调用函数的时候必须满足调用条件，就像物理公式不能乱套，厕所不能乱进一样。

PS：抱怨一下CU的代码编辑功能，排版难看。。。调整了几次

drangon

能够将代码写到恰到好处当然是最好了，但我们工程中的代码，距离这个境界差太远了，

要求程序员写精确的代码当然是好，但实际上很难操作，

倒不如退而其次，规定一些僵化的规则，宁可代码有点冗余，但只能能减少一些不必要的错误，也是值得的

对于一些高水平的程序员，能够写精确代码，可以不受僵化规则影响，但最怕那些眼高手低的程序员，
虽然大部分打破僵化规则的代码是合理的，但有小部分不合理的，也够喝一壶了。

为了安抚这种类型的程序员的情绪，高水平程序员也牺牲一下，大家都统一使用僵化规则，对整个项目还是有利的。

这些都是工程上的考虑，如果只是三两个人，写个小项目，那么另当别论。

donotblock

比较明显就是原本可能进入C++0x的concept，可惜被砍了。
按我的理解，契约并不见得是具体的语言特性，也 ...
幻の上帝 发表于 2010-11-19 22:19

    我说我怎么想不出有什么流行的语言直接支持这种隐式的契约。   C#推荐使用异常来检查这种隐式的契约条件,当然前提是正确的使用异常,因为我们可以假定调用者一般情况下会遵守这些隐式契约。对于C，我觉得如果调用者不遵守契约，就让函数crash掉比较好。

ddgfff

个人认为代码编写不必要冗余

因为你要编程，首先你要知道你自己在做什么，怎么去做，中间可能会遇到的障碍

并且你用哪种语言写，这种语言你应该是烂熟于胸，而不是概念不清

如果概念不清，写出有bug的程序是很正常的，因为你模棱两可

可能LZ会说，雇佣那么多概念清晰的人，好贵的，不好招聘

没错，但是用他干活你放心，如果手下没那么多对某种语言清晰的人，那就得考虑招人或者改用其他语言实现吧

donotblock

能够将代码写到恰到好处当然是最好了，但我们工程中的代码，距离这个境界差太远了，

要求程序员写精确的 ...
drangon 发表于 2010-11-20 11:03

    为啥要迁就那些不负责任的程序员呢？ 这是项目管理的问题了，不按照函数注释或说明调用，追究责任,就像15楼说的那样。 好像C的库函数很多也不做这种检查，现在大部分人不也能正确调用了么,这就是库函数不迁就调用者的原因。 越迁就项目质量越烂， 因为可能会有更垃圾的程序员加入进来,那岂不是要再加更多的冗余代码迁就这部分人？