代码大全读后杂记-03 子程序之提高内聚性、好名字、别乱用参数

【题外话】蟑螂竟然也可以入药...名曰蠊虫...好吧，希望大家身体健康，别遇到吃小强的那天！:evil:

内聚
“子程序的内聚，是指子程序中各操作之间联系的紧密程度”，Steve如是说；
对于子程序来说，内聚性主要有以下几个层次：
1.最好的内聚性
  功能的内聚性：
     即子程序只执行一项操作，这是最理想的内聚；当然名字也很重要，下面会提到命名的问题；

2.不够理想的内聚性
    a.顺序上的内聚性
      是指子程序内部包含了需要按照某特定顺序执行的操作，这些操作中间共享了数据，并且只有最后一步操作完成，才算完成了一项完整的工作；
      我经常写出这种具有顺序内聚的代码，作者认为，最好还是把这些操作提取到不同的子程序中间，然后用另外一个子程序分别调用之。    

    b.通信上的内聚性
      所谓通信上的内聚性，是指子程序之间的操作中间只是共享了相同的数据，但除此以外并无功能或逻辑上的联系。
      作者认为，这种情况下，也应该分而治之，分别提取这些操作为子程序，嗯，这点我赞同~

    c.临时的内聚性
      英文是Temporal Cohesion,我觉得应该翻译为时间上的内聚性吧~
      意思是说，将一系列需要同时进行的操作放置到一个子程序里头。比如，在Start()这种方法中，使用了装载文件，连接数据库等操作，作者认为最好将其中的操作按照功能再细分到不同的子程序中，再用某个方法调用。
      
   
3.不可取的内聚性
   a.过程上的内聚性
       是指一个字程序中的操作是按特定的顺序进行的，但这些顺序之间并无必须的前后关系或功能逻辑关系，只是为了满足某些外在的，或者习惯而放置在一起的
       我觉得为了避免这种内聚，就是要考虑清楚某些子程序中的部分代码是否是为了满足单一的功能而写到一起的      

   b.逻辑上的内聚性
      其实是非逻辑的内聚性，是指为了满足子程序的控制流或所谓“逻辑”而放到一起的一些列操作。比如，当你发现在你的if else中间或switch中的的那些代码彼此之间并无实质的联系，你该重构这个方法啦
    
   c.巧合的内聚性
       出于某种奇怪原因而拼凑的一起的操作...，整理一下这样的代码吧，毕竟写程序不是写文章~~ 


好名字
调查发现一个人的名字在一定程度上会影响这个人的人生（可阅读《怪诞心理学》一书）
好的子程序名也是必要的，下面是一些命名原则
1. 描述子程序所做的所有事情
     一个好的名字能够让使用者非常容易的使用和理解子程序，当然，最好你的子程序也是功能内聚的，否则，如果子程序中的功能过多，你可能会起出doSthAndSthAndSth这样的名字，着实不好看~

2. 避免使用无意义的，模糊或表述不清的动词
      就是要写的清楚明白，别用一些模棱两可的动词，比如do, handle类似的，谁知道你do啥子~

3. 不要仅通过数字来形成不同的子程序名字
      这大概是初级菜鸟才会犯的错误，把所有的子程序都命名为类似Method1,Method2......MethodN这样的玩意儿；好吧，我知道你数列学的好，当然如果你写的程序是葫芦娃的故事，然后你写了7个方法叫wa1，wa2，wa3，wa4，wa5，wa6，wa7...OK，You Win!

4. 根据需要确定子程序的名字长度
      一般来说9~15个字母就足够了，但这基本上是习惯或者经验，比如：在ObjectiveC中，就常常见到很长的子程序名

5. 给函数名民是要对返回值有所描述
      也就是说，人家通过函数名，能够大概知道你返回的是个啥，比如见到IsReady，IsConnect这样的，就知道返回的是个布尔变量

6. 起名的时候使用动宾结构
      其实这点也是为了准确说明问题提出的一个具体方法

7. 准确使用对仗词
      对仗词，好吧，就是互为反义词的词组；
      比如你用openFile来命名打开文件的函数，最好也用closeFile来命名关闭的函数；

8. 为常用操作建立命名规则
      由于在项目中，一般都有多个程序员完成，所以确立一套统一的命名规则是不错的选择


别乱用参数
在说参数问题前，先提一下一个子程序的长度是越长越好呢，还是越短越好？作者认为不一定，最好是错误越少越好，但一般来说，200行的子程序就差不多了

好吧，下面说参数，怎么样用才不是乱用呢？

1.按照输入-修改-输出的功用顺序排列参数
      按照参数的用途，首先是输入功用的参数，然后是即作为输入又作为输出的参数，最后是只作为输出的参数；

2. 考虑自己创建in和out关键字
     一般java或c++程序员不用考虑这个

3. 如果几个程序都用了类似的一些参数，应该让这些参数排列顺序一致
      因为这样子比较容易让人记住...

4. 使用所有的参数
      当然，没用的参数最好别占着茅坑，一是浪费，二是以后你来看代码，可能会花点时间来搞清楚这个参数放着原来是没用的

5.把状态或出错变量放在左后
      这也是对第一点的补充，一般来说状态或出左变量就是属于输出变量

6.不要把子程序的参数用做工作变量
      这是很危险的...

7.在接口中对参数的假定加以说明
      因为你假定了某个参数具有某种特征，就需要将此特征告知使用者，而且最好在写这段代码的时候就写注释（或者断言），因为那些打算以后再补注释的程序员八成都没那么干，哈哈
    
8.参数的数量应该限制在7个以内  
      还是由于人的记忆和理解力有限的缘故，当然，如果某个方法的参数太多，就需要重构之了

9.考了对参数采用某种表示输入，修改，输出的命名规则
      对于项目组来说，规则是好的，对于后来的阅读者（包括你）来说，也是一样~

好吧，就到这里，休息一下~~