回头看看从前写的代码

回过头来看了数个月之前写的filesort, 对当时的思路基本上都忘光了. 由于项目

需求的多变, 所以需要不时的在代码里加一些'表项'. 现在重新拿起这段代码, 粗

看了一下, 有几点感慨:

1. 代码注释的很烂. 写代码注释是一个技术活. 一直以来我都比较注意对自己写

   的代码注释, 但写了注释不代表写了好注释. 甚至有的注释还不如不要去写. 

   之前的代码里注释较零乱, 且注释不分清重. 

2. 代码结构不太好. 主要指对数据的组织结构处理的不好, 这样直接导致每次再

   对其中加一些'表项'时就很费力, 有时由于忘了这段代码原来是怎么写的而不

   敢在其中加东西, 所以不得不再去熟悉它. 这样会花费很多时间, 而且事倍功

   半. 

   一段代码写的好不好, 除了其逻辑功能要正确之外, 我想还要具备很好的伸缩

   性(可扩展性), 能够方便的对代码功能进行定制/添加. 

3. 不知道什么时候应该将一个功能分解成几个小的功能, 在代码里就表现为不知

   道可以将一个大函数分解成几个小函数. 导致许多代码都揉在一起. 这种代码

   不仅读起来恶心, 其作者写的时候其实也很恶心, 只是吐啊吐啊就行惯了.

4. 过重注重一些奇技淫巧. 代码里用到了如下的句子(这还算不上是奇技淫巧):

  if (__builtin_expect(errno != 0, 0)) {

   save = errno;

   cnt = -1;

  }

  这里不是在写内核代码, 只是在写一个功能模块并作为库的形式供别人使用. 想

  不通当时为什么这样写. 惭愧~

. 函数名/变量名起得真烂. 以后这些名字要好好取, 力求简单明了, 不然未来要

  下一代起名时可怎么办~

. 函数的参数, 不知道该传哪些, 不该传哪些. 所以只要用到, 就一股脑儿的当成

  作为参数传递. 

. 没有对自己的代码写测试用例. 偷懒的后果是以后会花更多时间和更痛苦的心情

  在这上面. 出来混的, 总归是要还的~

   现在感觉自己需要从如下几点改正:

   1. 尽量只对函数体做注释, 而不解释函数体内的单独语句. 

   一个函数是一个独立功能, 阅读代码时, 最重要的就是很快明确一个函

   数的功能. 而知道了函数的功能, 其内部实现也不会太难, 再对内部作

   解释显得有点多余了, 除非是很关键的点, 或用到某种算法等.

   2. 在写代码前, 特别是写一个库之前, 一定要对其功能作详细的分析, 这会体

      现在程序的数据结构上. 清晰的思路和明确的目的, 写文档的重要性呀. 

   3. 逻辑功能独立的代码抽出来作为独立的函数. 重复动作的代码抽成独立的函

      数减少代码复用. 

   4. 超过一百行的代码必须重写. 

   5. 尽量考虑程序的可扩展性, 积累这方面设计的方法.

   6. 命名统一风格. 这个可以在初始设计的时候就规划好.