回头看看从前写的代码

时间：2010-09-06 来源：changyongID

回过头来看了数个月之前写的filesort, 对当时的思路基本上都忘光了. 由于项目需求的多变, 所以需要不时的在代码里加一些'表项'. 现在重新拿起这段代码, 粗看了一下, 有几点感慨:
1. 代码注释的很烂. 写代码注释是一个技术活. 一直以来我都比较注意对自己写    的代码注释, 但写了注释不代表写了好注释. 甚至有的注释还不如不要去写.    之前的代码里注释较零乱, 且注释不分清重.
2. 代码结构不太好. 主要指对数据的组织结构处理的不好, 这样直接导致每次再    对其中加一些'表项'时就很费力, 有时由于忘了这段代码原来是怎么写的而不    敢在其中加东西, 所以不得不再去熟悉它. 这样会花费很多时间, 而且事倍功    半.    一段代码写的好不好, 除了其逻辑功能要正确之外, 我想还要具备很好的伸缩    性(可扩展性), 能够方便的对代码功能进行定制/添加.
3. 不知道什么时候应该将一个功能分解成几个小的功能, 在代码里就表现为不知    道可以将一个大函数分解成几个小函数. 导致许多代码都揉在一起. 这种代码    不仅读起来恶心, 其作者写的时候其实也很恶心, 只是吐啊吐啊就行惯了.
4. 过重注重一些奇技淫巧. 代码里用到了如下的句子(这还算不上是奇技淫巧):
  if (__builtin_expect(errno != 0, 0)) {    save = errno;    cnt = -1;   }   这里不是在写内核代码, 只是在写一个功能模块并作为库的形式供别人使用. 想   不通当时为什么这样写. 惭愧~
. 函数名/变量名起得真烂. 以后这些名字要好好取, 力求简单明了, 不然未来要   下一代起名时可怎么办~
. 函数的参数, 不知道该传哪些, 不该传哪些. 所以只要用到, 就一股脑儿的当成   作为参数传递.
. 没有对自己的代码写测试用例. 偷懒的后果是以后会花更多时间和更痛苦的心情   在这上面. 出来混的, 总归是要还的~

   现在感觉自己需要从如下几点改正:    1. 尽量只对函数体做注释, 而不解释函数体内的单独语句.    一个函数是一个独立功能, 阅读代码时, 最重要的就是很快明确一个函    数的功能. 而知道了函数的功能, 其内部实现也不会太难, 再对内部作    解释显得有点多余了, 除非是很关键的点, 或用到某种算法等.
   2. 在写代码前, 特别是写一个库之前, 一定要对其功能作详细的分析, 这会体    现在程序的数据结构上. 清晰的思路和明确的目的, 写文档的重要性呀.
   3. 逻辑功能独立的代码抽出来作为独立的函数. 重复动作的代码抽成独立的函    数减少代码复用.
   4. 超过一百行的代码必须重写.
   5. 尽量考虑程序的可扩展性, 积累这方面设计的方法.
   6. 命名统一风格. 这个可以在初始设计的时候就规划好.