CATEGORY / Development

代码之初,性本丑?(下)

Permanent Link: http://wutiam.net/notes/154

代码之丑(六)——分家的声明和使用

变量声明的就近原则,除了该文中提到的几点好处之外,还有一点就是能够提高发现声明了却未使用的变量的概率。别小看这个问题,以为编译器会给优化掉,我就碰到过一坨很烂的代码,这个函数里做了大量的计算,比如先经过复杂计算得到 a,然后 a 经过计算得到 b,b 再经过计算得到 c,c 再计算后得到 d,在一团乱麻的代码里,谁也没发现,其实 d 根本没被用到,函数最后直接拿 e 返回了……

代码之丑(七)——你的语言

这篇有点各抒己见的意思,不过我觉得有一点是明确的,学一门语言,主要是学习它的思维方式,而不仅仅学会语法就算完了。至于具体怎么用,这是每个 team 自己定编码规范的事了。

代码之丑(八)——不一致的困惑

这个例子都老的快成寓言故事了,不过就算如此,我们还是有同学把四种字符串类型随心所欲地混用的代码,其中一种是 STL 的、一种是 MFC 的、一种是第三方引擎库的、一种是他不知道从哪个网页里抄来的。原因也正如该文里提到的,每种字符串类型都有他想用的功能,但有时又缺点什么。于是乎 ,呵呵,debug 这样的代码是痛苦的,大量的类型转换,大量的字符串内存分配,仅仅是为了满足他不同函数间定义的形参或返回值类型的不同。

我觉得,不仅仅是软件设计要尽可能的保证一致性和唯一性(就像《人月神话》中所说的外科手术团队模式,也是我非常赞同的),编码等具体事物也需要有一致性,这不仅仅是效率和可维护性的问题,而是一个人、一个团队的态度问题,一个“大心脏”的程序员(见第五篇),他的代码能给谁带来安全感?

代码之丑(九)——退让的缩进

缩进是个永恒的话题。两个空格、四个空格、一个 tab,{} 跟上一层对齐还是跟下一层对齐,其实这些都不重要,重要的是明白缩进是为了什么?可读性!当然是可读性!就算 Python 的缩进含有控制的功能,那也是因为看明白了可读性的重要性。

从理论上讲,一个函数不能太长,一个条件也不能太长,一个循环更不能太长,所以缩进也不能有太多层,谁不希望是这样呢?大部分的冗长代码确实可以通过改变设计来拆分甚至是消除丑陋,可是现实总是残酷的(比纸上谈兵残酷得多),有些情况从逻辑上讲已经是原子操作的了,但从代码角度却依然有大量跳转计算和前后依赖,这就存在一个如何折衷的问题了。把连续依赖的 10 小段代码分别挪到 10 个独立的函数中去?想想假如在看书的时候全文都是“参见 XX 页 xx 段”的情况,这样的书有人爱看么?

所以,缩进不是可读性的唯一,连贯的思路也一样非常重要。

代码之丑(十)——条件编译那些事儿​

该文基本都说得差不多了,这也是这几年比较流行的改进方法,最近看了几个引擎的代码,确实舒服多了。但有一点要注意,是否拆分到文件,还是得看具体的功能是否强依赖于平台,如果依赖度较低,虽然拆到独立文件后可读性很高了,但维护性却大大降低了。为什么?DRY —— Don't Repeat Yourself!

后话

说得够多了,类似《代码大全》上的观点本来没必要那么多人反复的说。但是,就算已经有那么多人反复的说过了,工作中大部分人还是坚定地认为(至少潜意识里认为),“程序么,能跑就好了,你看,功能好得很呢”。嗨!真的是大部分人呢。所以只好再多说一次,多说一次,总可能会多影响一个人,也是好事。

费那么大劲说,费那么大劲做,图什么,无非是想要明天的日子好过一些。说来说去,还是一句老话:性格决定命运,气度决定格局,细节决定成败,态度决定一切

No Comments / Trackbacks / Pingbacks

Leave a Reply

:) :wink: 8-O :lol: :-D 8) :-| :mrgreen: :oops: :-o :-? :( :twisted: :cry: more »