软件编码规范及基本注意事项(discuz缺陷)

自由不是所心所欲,而是自由选择最适合的方式。

最近接手了论坛,我还记得前任维护者那同情感叹的眼神,事到如今,我也知道为什么了。

第一条:不要随便使用全局变量,不要随便全局变量,不要随便使用全局变量

在阅读discuz源码的时候,时常看到一个变量,不明白什么含义,经历怎样的处理,来到当前所在的地方,往往需要回溯,变量的定义可能是上层文件(该文件include/require本文件),也可能是自己include的子文件,随随便便的一个global,就将自己查找范围扩大无数倍,更有甚者,discuz将Get/Post/Server中的变量提出来,通过&&$_POST[$key] = $val的方式,硬生生的把一个本来还容易理解的全局变量,变成了极其容易和局部变量混淆的变量,结果就是回溯,回溯,再回溯。global有时候是必须的,但不是随意的,甚至是危险的,有时候,会和普通变量重名,互相干扰,可能在无意中被修改,过长的作用链,从前向后贯穿整个代码生命周期,也极大的增加了耦合度,复杂度。

第二条:注释很重要,真的很重要。

一个几乎没有注释的代码,会让后来的接手者痛不欲生,写代码的时候,书写的人只有一种想法,但是后来的人却需要在1000种猜测选择中来回揣摩,以及不断的印证,花费的时间,远远超过维护一份好的注释的时间。

第三条:尽可能的复用代码,使用函数,通过参数传递变量。

阅读一份800+行代码,没有一个函数,全部平铺直叙的写下来,看起来让人昏昏欲睡,这样的代码,完全是写代码的的人不肯动脑子,没有仔细思考某一个功能的独立性,没有考虑复用的可能,看着if和else里面惊人相似的代码,这么长,这么长,他们到底有什么不同,恨不得在脑子里面实现diff,单纯的一个if/else ,15寸的屏幕还放不下。用函数,把巨大的代码块切割成一个一个的小func,然后组织起来,阅读起来轻松愉快,后续更改维护,也不会牵一发而动全身。

软件工程里有一个约定,就是一个函数的长度,不要超过一个屏幕,这个是非常必要的。当然,还有一个过期的约定,就是宽度尽量不超过80个字符,redis的作者居然也还在恪守着这个原则。

我阅读过PHP的软件规范,大括号的位置,= if 左右的空格,变量的命名等等约定,相比于上面几条来说,都是浮云,这些做不好,挺多就是难看点,上面的做不好,就是要人命的。而且,上面的,真的是软件开发里面最最基础的,相信大部分人都知道。

2 Comments on 软件编码规范及基本注意事项(discuz缺陷)

  1. 说好的编码规范和注意事项呢?难道仅回复可见?回复一个试试

Leave a Reply to unasm Cancel reply

Your email address will not be published.

*