像说话一样写代码

1  层次感 。当你说明如何做一个复杂的事情的时候，通常你会说，“首先……；然后……；最后……。对于第一步…… ( 可能又是一串的首先，然后，最好 ) ”。从总到分，层次感让听众可以比较清晰地接受。代码的表达可能是这样的：

         class Man 
        { 
                 void Execute() 
                { 
                        ExecuteStep1(); 
                        ExecuteStep2(); 
                        ExecuteStep3(); 
                }    
              void ExecuteStep1() 
             { 
                     ExecuteStep1-1(); 
                     ExecuteStep1-2(); 
             } 
                …… 
        }

但如果同样的过程变成了这样：

         class Man 
        { 
                 void Execute() 
                { 
                        ExecuteStep1(); 
                        ExecuteStep2-1(); 
                        ExecuteStep2-2(); 
                        ExecuteStep3(); 
                }    
                …… 
        }

    可能结果是一样的，但层次感的破坏使得代码读起来很“颠簸”。因为你可以试想下把原来的问题按这种代码逻辑解释，是否也会一样的“颠簸”呢？

 

2  先后顺序 。办理房贷的时候工作人员通常会这样对你说，“你把这些证件和资料都准备好了，我们这边就可以放贷了。否则，我们将要想其它办法了。”代码版的这种表述如下：

         class Man 
        { 
                 void ProcessLoan () 
                { 
                         if(AllCertificatesReady()) 
                        { 
                                ApproveLoan (); 
                        } 
                         else 
                        { 
                                DeclineLoan (); 
                                ErrorNotification(); 
                        } 
                } 
        }

    如果代码写成下面这样。从结果上看是等效的，但如果用语言表达就可能变成，“如果你没有把这些证件和资料都准备好，我们将要想其它办法了。否则，我们这边就可以放贷了。”是不是觉得有点不自然和不容易接受啊。同样读下面这段的时候你是否会感觉需要一个停顿和思索，这样就破坏了代码的流畅。

         class Man 
        { 
                 void ProcessLoan() 
                { 
                         if(!AllCertificatesReady()) 
                        { 
                                DeclineLoan(); 
                                ErrorNotification(); 
                        } 
                         else 
                        { 
                                ApproveLoan(); 
                        } 
                } 
        }

     所以，在分支语句中最好把正常的、发生概率比较高的先处理，然后处理低概率的异常和错误的。

 

3  多选项 。记得有回我去联通营业厅申请一张新的电话卡，就向服务员问起了资费。“市话每分钟多少钱 ? ”，“国内长途呢 ? ”，“国际长途呢 ? ”……，回答前面几个问题的时候那服务员态度还挺好的，但到了后面就显得有点不耐烦了。我后来想想，如果代码写成下面这样子，我们会有什么感觉呢？

         class TeleCom 
        { 
                 double GetFeePerMinute( int type) 
                { 
                         switch(type) 
                        { 
                                 case 市话: fee = 0.2; 
                                 case 国内长途: fee = 0.5; 
                                 case 国际长途: fee = 2.5; 
                                ... 
                        } 
                         return fee; 
                } 
        }

    最后服务员拿了一个电话卡的宣传单给我，“你自己看看吧！”。宣传单上面有一张资费表格，一目了然。所以上面的代码可以是这样的：

         class TeleCom 
        { 
                 double GetFeePerMinute( int type) 
                { 
                        fee = FeeTable(type); 
                } 
        }

    编程过程中通常会遇到这样多选项的问题，这可能是 switch 或 if…else if…else 语句派上用场的时候，通常也会使引入代码“坏味道”的时候。所以使用之前你是否应该考虑用一些设计上或者实现上的技巧避免冗长的代码呢？

 

4  关注点 。一般每次说话都会有一个关注点，以便更好地传递信息或解决问题。当然，侃大山除外。因此说话有时候很忌讳漫无主题和不时跑题，这类现象对应的代码可能是这样的：

         class Man 
        { 
                 void Talk() 
                { 
                        Problem1 Block; 
                        Problem2 Block;  // By the way 
                        Problem1 Block;  // Back again 
                } 
        }

    但一旦有了关注点，代码就会变成：

      class Man 
        { 
                 void Talk() 
                { 
                        Problem1 Block; //Always focus on it 
                } 
        }

    这样，代码就会遵循函数级别的“单一职责原则”，从而便于阅读和维护。

 

5  专家原则 。某天，有个同事想问你一个你不是很有把握的技术方面的问题，你出于面子鼓起勇气向他解答。随着解释的深入，你开始发现自己也迷糊了。最终不但没有解决你同事的问题，而且把你自己也套进去了。对应的代码可能会是：

  class Man 
 { 
          void ExplainSomething() 
         { 
                 Complicated and error-prone code block here... 
         } 
 }

    这时你可能会很无奈的说，“张工对这很熟悉，这问题可以问问他”。其实这里遵循的就是“专家原则”，就是可能的情况下，应该让最合适最胜任的人处理问题。这样故事就可以用如下代码表示。

  class Man 
 { 
          void ExplainSomething() 
         { 
                 expert.ExplainSomething() 
         } 
 } 

 

6  解释 。如果你说一件事的时候不断有人打断你问你刚说的东西。你有可能就要意识到要不你说的问题太难了，要不你就没有把问题说清楚，因此再多的解释可能都无助于最终把事情说清楚。对于写代码，注释就是解释。除非在非常必要的时候进行适当的注释，否则只会增加阅读代码“噪声”。写一些“挂羊头卖狗肉”的注释更是害人非浅。

 

本文出自 “ 林家男孩” http://bj007.blog.51cto.com/1701577/330932

转载于:https://blog.51cto.com/manchester1878/342450