组织代码顺序

以上是组织代码顺序的思路。下为总结内容。

 

1 代码执行顺序

    通常我们对写程序对数据操作都是取数，对数据进行计算，再打印。一段java演示代码如下：

data = ReadData();

results = CalculateResultsFromData( data );

PrintResults( results );

     这三个步骤思路非常清晰，说明了这几个函数之间的耦合程度，和相互依赖性。除非什么特殊情况发生，否则都会按照这个顺序来执行。尤其在ABAP中，似乎都是这样的顺序。

     再看一个例子：

revenue.ComputeMonthly();

revenue.ComputeQuarterly();

revenue.ComputeAnnual();

      在以上代码中先计算的是月份，接着是季度，最后是年份。这是一个常识，但是光从代码中我们无法得出他们是否有耦合，是否应该按照这个特定顺序执行。

再看一个VB例子：

ComputeMarketingExpense

ComputeSalesExpense

ComputeTravelExpense

ComputePersonnelExpense

DisplayExpenseSummary

      从以上例子中也看不处这段代码的执行顺序有什么特殊之处，也不知道如果改变语句的执行顺序会怎样。没有任何的注释，程序也没有参数，可能都是直接对全局变量进行操作。所以这段代码写的并不好。

 1.1 如何组织代码执行顺序

      在上面的VB代码中，应该有一个初始化函数，如InitializeExpenseData()。写这个函数的目的是程序的结构更清晰，让读代码的人知道了一个隐含的信息，在调用其它函数之前，必须调用初始化函数。

      使用函数参数让函数依赖关系更加明显。在以上VB代码中，没有数据在函数间传递，我们并不知道这些函数是否使用的是同样的数据。这点在ABAP中也是，大多数代码都直接对全局变量操作，应该在函数参数这修改下，即使是对全局变量操作，也要让函数声明清晰的告诉读代码的人这个函数用了哪些全局数据。经修改后的代码如下：

expenseData = InitializeExpenseData( expenseData )

expenseData = ComputeMarketingExpense( expenseData )

expenseData = ComputeSalesExpense( expenseData )

expenseData = ComputeTravelExpense( expenseData )

expenseData = ComputePersonnelExpense( expenseData )

DisplayExpenseSummary( expenseData )

         这些函数都是将expenseData作为输入，和输出。明确的表明了代码的执行顺序不能改变，这些代码之间是有依赖关系的。

再看一个VB例子：

ComputeMarketingExpense( marketingData )

ComputeSalesExpense( salesData )

ComputeTravelExpense( travelData )

ComputePersonnelExpense( personnelData )

DisplayExpenseSummary( marketingData, salesData, travelData, personnelData )

       可以看到前4行代码所使用的参数并不相同，所以更改它们的执行顺序是可以的，应为它们之间并没有依赖关系。但是最后一行代码的执行必须在末尾处。

有时难以通过参数表明函数执行顺序的依赖，那么就通过注释，不过注释应该是最后的选择，self-document code才是最佳。

1.2 检查代码的依赖性

      如果对代码安全性要求很高的话，可能还需要其他的方法来检查代码的执行顺序。如设置布尔变量，来判断是否已经执行了相关的操作。

2. 代码顺序对程序无影响的情况

     总有这样的一种情况，代码的执行顺序对程序不会有影响。那就始终抱着一个原则：Keep related actions together.有一个c++的例子如下：

MARKETING_DATA *marketingData = new MARKETING_DATA;

SALES_DATA *salesData = new SALES_DATA;

TRAVEL_DATA *travelData = new TRAVEL_DATA;

travelData.ComputeQuarterly();

salesData.ComputeQuarterly();

marketingData.ComputeQuarterly();

salesData.ComputeAnnual();

marketingData.ComputeAnnual();

travelData.ComputeAnnual();

salesData.Print();

delete salesData;

travelData.Print();

delete travelData;

marketingData.Print();

delete marketingData;

      上面的代码例子可以看到，如果你想对marketingData是怎样计算的，你必须从第一行开始看起，直到最后一行。下面是一个组织的较好的例子：

MARKETING_DATA *marketingData = new MARKETING_DATA;

marketingData.ComputeQuarterly();

marketingData.ComputeAnnual();

marketingData.Print();

delete marketingData;

SALES_DATA *salesData = new SALES_DATA;

salesData.ComputeQuarterly();

salesData.ComputeAnnual();

salesData.Print();

delete salesData;

TRAVEL_DATA *travelData = new TRAVEL_DATA;

travelData.ComputeQuarterly();

travelData.ComputeAnnual();

travelData.Print();

delete travelData;

       这段代码将相似的操作局部化了，这样在关注与一个变量的时候，只用关注与这一点，不用从头到尾查找代码。对于组织的不好的代码，我深有体会。一个几千行的代码，我看了半天不知道它到底干什么，每次看到这样的代码我就重写的冲动，而不是修改。

       局部化了之后，可以将每一部分都能写成一个function，更加模块化。

2.2 组织代码优劣的判断

       如何判断将一段代码组织的清晰易懂了？一个简单的方法就是将相关联的语句用方框画出来，如果没有重叠，那么代码是不错的。如图：

       如果代码组织的不好，画出的方框很可能是这样的：

      这样思路就比较混乱，看代码的人也很郁闷，需要花较长的时间才能读懂代码。