代码之丑——开篇
时间:2010-12-02 来源:gzhuotao
我是一个程序员,也是一个咨询师。
成为咨询师之后,我有机会在不同的项目中穿梭。同客户合作的过程中,我经常干的一件事是:code diff,也就是用源码管理工具的diff功能把当天全部修改拿出来,从编码的角度来分析代码写得怎么样。
因为这个工作,我看到了许多不同人编写的代码,我的编码底线不断受到挑战。许多东西,我以为是常识,但实际上不为许多人所知。比如,下面这段代码,你会做何感想?
if(db.Next()) {
return true; |
有的人会想,怎么写得这么笨啊!但是,请放心,绝对会有人这么想:挺好的,实现功能了。这并非我臆造出的代码,而是源自一个真实的codebase。
这些代码的存在,给了我很多机会与人分享一些编码的心得。其间,有人建议,为什么不能把你说的这些内容写下来,与更多人分享。于是,有了这个即将看到的系列:《代码之丑》,以此向《代码之美》致敬。
最后要说的是,上面那段代码可以写成这样:
return db.Next(); |
以下是原出处的评论(摘抄):
其实无须大惊小怪
2010年11月16日 上午6时3分 发表人 Yetao Chen
更烂的代码有的是,远远可以挑战人们的想象底线...
“绝对会有人这么想:挺好的,实现功能了”,这是一个广泛存在的东西。很多做老板的人都这样想,比如我的老板,虽然在澳洲,他的公司也算相当大了,但他依然觉得,东西可以用就好了。不过,像我们这种inhouse的开发,估计也就是这样了。
你知足吧,好歹你在ThoughtWorks,起码你对于代码质量的追求是会得到认同和赞许的。
刚毕业的时候,总期望能赶紧找到工作,现在我觉得,能跟一群志同道合的人一起工作,比什么都重要。
--------------------------------------------
这个代码不算丑
2010年11月16日 下午9时2分 发表人 Liu Tiger
从工程学的角度看,这个代码一点也不算丑,逻辑清楚,没有隐患,易读,一点点额外开销几乎可以忽略不计,最多只能算是不够精炼而已。
--------------------------------------------没有问题吧。
2010年11月17日 下午11时2分 发表人 jianming guojm
这种处理解决虽然可以直接采用return的模式进行处理,但是如果是另外一个函数调用了这个代码函数,如何写取决于外部对于返回值的处理,不能一概而论这种代码就是“丑”。应根据实际情况判定。
--------------------------------------------Re: 环境使然
2010年11月24日 上午3时14分 发表人 Li HongQing
不能这么写 return db.Next(); 应该加上if(db!=null) { return db.Next();}
--------------------------------------------这是命名不规范造成的
2010年11月24日 下午7时22分 发表人 Yi Bo
想想看,如果那个db.Next()还有一个方法叫db.hasNext()调用API的人就不会再傻乎乎的去判断true或者false了
--------------------------------------------
代码有丑的地方,但不是 if else
2010年11月25日 上午2时30分 发表人 wu camry
db.Next() 这个调用不是很明确,也许是访问 db 中下一个元素,也许是看 db 是否有下一个元素。像上面回复的兄弟说的那样,要叫 hasNext 好些。
if else 在这里用完全没问题,很清晰明白,让人一眼知道这个函数的返回值是什么。
直接 return db.Next(); 其实不算优美,咋一看去,尤其从 diff 中看去,都不知道说什么。
只是简洁一些而已。
并不是简单的简笔画就一定比复杂的素描来得优美的。
Re: 代码有丑的地方,但不是 if else
2010年11月25日 下午10时27分 发表人 邵 毅
同意这个观点。代码的可读性比简洁更重要。毕竟代码不光要写,还有很大一部分工作在于维护。
--------------------------------------------这不单单是个技术问题
2010年11月30日 下午11时21分 发表人 qin wei
boss只给2天时间,要求完成N多功能。我告诉他,这样质量很难保证,他回复我,能用就行。