《代码大全2》第14章 组织直线型代码

目录

前言

14.1 必须有明确顺序的语句

14.1.1 组织语句的原则

14.2 顺序无关的语句

14.2.1 使代码自上而下的阅读

14.2.2 把相关的语句组织到一起

---

《Code_Complete_2》持续更新中......_@来杯咖啡的博客-CSDN博客这本书有意设计成使你既可以从头到尾阅读，也可以按主题阅读。1. 如果你想从头到尾阅读，那么你可以直接从第2章“用隐喻来更充分地理解软件开发”开始钻研。2. 如果你想学习特定的编程技巧，那么你可以从第6章“可以工作的类”开始，然后根据交叉引用的提示去寻找你感兴趣的主题。3. 如果你不确定哪种阅读方式更适合你，那么你可以从第3章3.2节“辦明你所从事的软件的类型”开始。.....................https://blog.csdn.net/qq_43783527/article/details/126275083

前言

        本章从以数据为中心的编程观点转到以语句为中心的观点上。本章介绍最简单的控制流：即按先后顺序放置语句和语句块。

        尽管组织直线型代码是一个相对简单的任务，但代码结构上的一些微妙之处还是会对代码的质量、正确性、可读性和可维护性带来影响。

14.1 必须有明确顺序的语句

        最容易组织的连续语句是那些顺序相关的语句。下面举一个例子：

        除非这段代码里发生了某些不可思议的事情，否则这些语句必须按照所显示的顺序依次执行。在计算数据之前必须要先读入数据，而在打印之前也必须先计算出结果。
        这个例子中潜在的根本概念与依赖性有关。第三条语句依赖于第二条，第二条依赖于第一条。在本例中，前后语句之间的依赖关系可以很明显地从子程序名中看出来。在下面的代码段中，依赖关系就不那么明显了：

 在这个例子中，对季度收入的计算要求假定月收入己经计算出来了。熟悉会计学的人——甚至常识——可能会告诉你必须先计算季度收入，然后才能计算年收入。这就是一种依赖，但是这一点仅仅通过阅读代码是不太看得出来的。

14.1.1 组织语句的原则

         如果语句之间存在依赖关系，并且这些关系要求你把语句按照一定的顺序加以排列，那么请设法使得这些依赖关系变得明显。下面是一些用于组织语句的简单原则。
        1、设法组织代码，使依赖关系变得非常明显。 在刚刚给出的那个 MicrosoftVisual Basic 示例里，ComputeMarketingExpense(） 不应该初始化类的成员变量。那里所用的子程序名暗示 ComputeMarketingExpense() 类似于 Computesales-Expense()、 ComputeTravelExpense(） 和其他的子程序，只是它处理的是marketing 数据而不是 sales 数据或者其他数据。让 ComputeMarketingBxpense()来初始化成员变量是一种应该避免的草率的措施。为什么要在这个子程序里执行初始化而不是由其他两个语句中的某一个来做？除非你能给出一个好的理由，否则就应该另外写一个子程序，如 InitializeExpenseData()，来初始化成员变量。这个子程序的名字清楚地表明了程序员应该在运行其他的开支计算子程序之前调用它。
        2、使子程序名能突显依赖关系。 在 Visual Basic 示例里，ComputeMarketing-Bxpense() 的命名是错误的，因为它做的不仅仅是计算 Marketing 费用；它还初始化了成员数据。如果你反对再写一个子程序来初始化该数据，那么至少要给ComputeMarketingBxpense()一个能够反映它所执行的全部功能的名字。在本例中，ComputeMarketingBxpenseAndInitializeMemberData（） 就是一个适当的名字。你也许会说这个名字太糟糕了，因为它太长，但是它却描述了这个子程序做了什么，因此并不算糟糕。实际上是这个子程序本身太糟糕了！

        3、利用子程序参数明确显示依赖关系。 还是针对那个 Visual Basic 示例，在那些子程序之间没有传递任何数据，由此你不知道有哪些子程序使用了相同的数据。通过重写代码让数据在子程序之间传递，你就可以暗示执行顺序是很重要的。新写的代码看上去会是这样：

    由于所有的子程序都使用了 expenseData，你会从中得到提示，即它们可能操作了相同的数据，因此这些语句的顺序可能是重要的。
    在这个特殊的例子里面，还有一种可能更好的方法，即把这些子程序转变成输入 expenseData 并把更新过的 expenseData 作为输出加以返回的函数，这样就使代码中包含顺序依赖关系的这一事实变得更加明显。

 也可以用数据来表明执行顺序并不重要，如下例所示：

         前面四行中的子程序不包含任何共同的数据，因此这一代码表明它们的调用顺序并不重要。而由于第五行中的子程序使用了来自前四个子程序中每一个子程序的数据，因此你可以认为它需要在前四个子程序之后执行。

         4、用注释对依赖不清晰的代码进行描述。依赖于那些技术，而不是依赖于注释。但如果你是在维护控制得非常严格的代码，或者由于一些其他的原因使你无法改进代码本身，那么就用文档来弥补代码的不足吧。

14.2 顺序无关的语句

        你也许见过这种情形，即代码中若干语句或语句块的先后顺序看上去完全没有关系。一条语句并不依赖于或者在逻辑上承接另一条语句。但是顺序的确对可读性、性能和可维护性有影响，而且当缺少执行顺序依赖关系的时候，你可以用第二标准来判断语句或者代码块的顺序。这其中的指导原则就是就近原则(Principle of Proximity)：把相关的操作放在一起。

14.2.1 使代码自上而下的阅读

        作为一条普遍性原则，要让程序易于自上而下阅读，而不是让读者的目光跳来跳去。专家们认为自上而下的顺序对提高可读性最有帮助。简单地让控制流在运行时自上而下地运行还不够。如果有人在阅读你代码的时候不得不搜索整个应用程序以便找到所需的信息，那么就应该重新组织你的代码了。下面举一个例子：

假设你希望知道 marketingData 是怎么计算出来的。你就必须从最后一行开始，跟踪所有对 marketingData 的引用直至回到第一行。marketingData 只在代码中其他少数的几个位置用到，但你却不得不集中精力去想：是否在从头到尾的每行代码中都用到了 marketingData。换句话说，为了理解 marketingData 是如何计算的，你必须要查看并且考虑这段代码块中的每一行代码。更何况这个例子当然比你在实际系统里看到的代码简单得多。下面是组织得更好的完成同样功能的代码：

 这段代码在很多方面都好。把对每一个对象的引用都放在一起；把它们“局部化(localized)”了。对象“存活”(live）的代码行数非常少。然而也许最重要的是，这段代码现在的样子说明它可以拆分为分别计算 marketing、 sales 和 travel数据的子程序。第一段代码却没有暗示这样一种分解是可能的。

14.2.2 把相关的语句组织到一起

        把相关的语句放在一起。一些语句之所以相关，是因为它们都处理了相同的数据、执行了相似的任务，或者具有某种执行顺序上的依赖关系。

        检查相关的语句是不是组织得很好起来的一种简便方法是，打印出你的子程序代码，然后把相关的语句画上框。如果这些语句排列得很好，你就会得到类似于图14-1那样的图形，其中的方框是不会彼此交叠的。