关于代码的适度冗余

drangon

对眼高手低的孩子应该教育，但简单的冗余编程是可能让他们变得眼低手低的。

    一个项目里， ...
狗气球 发表于 2010-11-22 08:45

对程序员的教育，以及程序员的自我修炼，是必要的，但是可以有很多方法的，不一定非得在当前工程项目里面锻炼的。

先用一些僵化的规则减少当前工程项目的风险，程序员自己提高水平，后面的项目如果程序员水平提高了，再更新规则都来得及

unistd

眼高不高，手低不低，不仅仅是由你自己的水平决定的，还和你老板的压力和工作量有关系。。，。。

再牛逼的程序员，时间紧了，照样也写不出优秀的代码来。

狗气球

回复 32# drangon


    “程序员自己提高水平”，我不知道你的经历是怎么样，至少我所在的公司里这事儿指望不上。
    愿意学习的人总会想办法，这是一个方面。如果管理上抑制学习提高，那又是一个方面。
    我没说防御型编程会抑制学习。然而是有相关性的。

米兰2010

回复 1# JohnBull


    看了你的那么多帖子，你的很多观点我都同意，特别是编程习惯。
   但关于这个观点我不太同意，冗余，可以通过系统设计角度去考虑，但是代码必须精简（一些维护手段的代码还是必须滴）。
  微软名言：代码一经生成，就是成本。各种各样的成本，学习成本，维护成本等等。。

米兰2010

回复 27# zhangsuozhu


    int func_xxxxx(char *str)
{
     if(!str)
         return 0;
     ................
}

int func_yyyyy()
{
      ...............
      if (str)
             func_xxxxx(str);
      ...............
}

红色部分判断了二次。大家觉的有问题吗？
*****************************
str在func_yyyyy除了作为入参，会不会被直接使用？如果有，这个保护是必须的。如果只是作为func_xxxxx入参，那么这个是没有必要的。

cx6445

大多人都认没有必要冗余，不过一点没有冗余的代码几乎在产品中看不见。如果有也必定符合一个要求，需求简单且不太变化。

冗余是种常态，只不过需要根据项目情况动态来判断。我见过两类程序员，一种写代码很慢，但是写出来的代码漂亮。另一类简单粗暴，但是编码速度快，完成商业目标很快。
对于商业来说第二种的成本更低。但是大型项目而言，代码结构不好显然很致命，所以过程的选择需要根据人力资源、项目背景来综合判断的，没有简单一条规则能说明问题的。

donotblock

大多人都认没有必要冗余，不过一点没有冗余的代码几乎在产品中看不见。如果有也必定符合一个要求，需求简单 ...  另一类简单粗暴，但是编码速度快，完成商业目标很快。
cx6445 发表于 2010-11-23 08:04

   这个。。。如果你这个商业项目从编码开始需求就固定不变了我觉得ok，虽然debug还是困难。  但问题是我做过的大部分项目，在编码开始后需求还是会有很多变化，那这种简单粗暴的编码只会令整体进度更慢，因为在需求变化的时候容易出bug，而且难调试。  尽量简单可以，不能粗暴

chinesedragon

确实是需要的