14.1 语句必须明确顺序

文章目录
  1. 1. 设法组织代码,使依赖关系变得非常明显
  2. 2. Name routines so that dependencies are obvious 使子程序名能突显依赖关系
  3. 3. Use routine parameters to make dependencies obvious 利用子程序参数来突显依赖关系
  4. 4. Document unclear dependencies with comments 用注释说明不清晰的依赖关系
  5. 5. Check for dependencies with assertions or error-handling code 用 断言 或 错误处理代码 来检查依赖关系

首先尽力写没有顺序依赖关系的代码,其次尽力写依赖关系明显的代码

如果语句间存在依赖关系,而且这些关系要求你把语句按照一定的顺序排列(即必须按这一顺序执行),那么要设法将这些依赖关系变得明显,使得阅读代码时可以看出来

note: 何谓依赖关系?一段代码中的语句们必须按照特定的顺序执行,则称这些语句间存在依赖关系。如,在 用户输入 - 处理 - 输出结果 的过程中,必须按照这一顺序书写相应语句,否则程序会出错

设法组织代码,使依赖关系变得非常明显

例子:

basic
1
2
3
4
ComputeMarketingExpense '计算市场费用
ComputeSaleExpense '计算销售费用
ComputeTravelExpense '计算旅行费用
DisplayExpenseSummary '显示花费报表

明显,DisplayExpenseSummary 必须要在最后执行。而前面三个计算花费的子程序貌似可以打乱顺序(而且他们应该这样做)。可是新手小明在ComputeMarketingExpense里初始化了类的成员变量,以便其他计算费用的子程序可以将数据放进去。——也就是说,在这样的情况下,ComputeMarketingExpense 必须放在第一行。而我们只通过阅读代码是看不出来这样的依赖关系的。

应该做如下修正:

basic
1
2
3
4
5
InitializeExpenseDate '初始化成员变量,而不是在 ComputeMarketingExpense 里做这件事
ComputeMarketingExpense '计算市场费用
ComputeSaleExpense '计算销售费用
ComputeTravelExpense '计算旅行费用
DisplayExpenseSummary '显示花费报表

Name routines so that dependencies are obvious 使子程序名能突显依赖关系

还是上面的例子,ComputeMarketingExpense 的命名是错误的,因为它不仅计算市场费用,还初始化了成员数据——但这一功能没有反映在名字里

子程序的命名应该能完整描述子程序所执行的全部功能,这样才能看出语句间的依赖关系

Use routine parameters to make dependencies obvious 利用子程序参数来突显依赖关系

toNote

再研读书中的例子 349页

重写代码让数据在子程序间传递,就可以暗示执行顺序是很重要的

  • 当所有的子程序都操作了相同的数据,会暗示你:这些语句的顺序可能是重要的

也可以用数据来表明执行顺序并不重要,例如将参数进行不同的命名,来表示这些子程序不包含共同数据,从而表明调用顺序并不重要

Document unclear dependencies with comments 用注释说明不清晰的依赖关系

首先尽力写没有顺序依赖关系的代码,其次尽力写依赖关系明显的代码,如果担心不够清楚,用文档来说明它

toExemplify-book

但编写代码时更应该使用其他技术来改进,而不是依赖于注释,除非你很难获得权限去修改代码本身

Check for dependencies with assertions or error-handling code 用 断言 或 错误处理代码 来检查依赖关系

可以借助状态变量来记录某个子程序执行的必要条件的状态,在执行子程序前,用断言、处理代码来检查执行的必要条件是否已经成立

注意,因为引入了额外的(变量、初始代码和错误处理代码),所以复杂度上升了,请在由此获得的好处和增加的出错率间做出权衡