App Inventor编程开发集锦1-水果配对-第7课-代码整理

第7课 代码整理

图1- 65 游戏中的全部代码在一个游戏开发完成之后，整理代码是一个非常好的自我提升机会，它可以让开发者站在一个全局的高度审视开发过程，将宝贵的开发经验真正地收入囊中。图1- 65中列出了应用中的全部代码（略去了用于测试的部分），其中包括7个全局变量、6个自定义过程以及20个时间处理程序，App Inventor的编程视图中，在折叠了所有代码之后，可见的就只有这三类代码，其他代码都被封装在这三类代码中。需要提醒读者的是，不要忽视代码的排列，建议按照从左向右按顺序排列变量、过程及事件处理程序，养成习惯之后，会让自己的开发工作变得井井有条。

这里再推荐一种要素关系图，图中包含了项目中的各类要素：组件（属性）、变量、过程及事件处理程序，同时给出了各个要素之间的调用或设置关系，其中的黑色箭头表示对过程的调用，红色箭头表示对变量的改写，而绿色箭头表示对组件属性的设置。它不仅可以帮助我们从整体的角度去认识程序，还能够对程序的优化提供思路，如图1- 66所示。

图1- 66 要素关系图图中箭头指向的要素是被调用（过程）或被改写（变量或组件属性）的要素，这样做的好处之一是，我们可以从中看到某个变量的变化原因。例如全局变量剩余时间，有两个红色箭头指向该变量，它们分别来自游戏初始化过程及游戏计时程序，其中前者将其设置为最大值（60毫秒），而后者对其执行-1的运算。这样，当程序的某个环节出现错误时，很容易逆着箭头的方向找到问题的所在。

此外，这个图也可以帮助开发者做代码的优化。例如，在屏幕初始化程序中有四行代码，其中除了调用创建按钮列表过程之外，其余代码都包含在游戏初始化过程之中，可以在屏幕初始化程序中，直接调用游戏初始化过程，这样优化了程序的结构，也提高了代码的复用性。

注意到图1- 66中有一个空闲的全局变量——图片列表，没有任何箭头指向它。这很容易理解，在程序运行过程中，它的值只是被读取，而不曾被改写。在一般的编程语言中，有一种语言要素被称为常量，与变量不同的是，它的值在程序运行过程中保持不变，像图片列表这样的数据就可以保存在常量中。

我们可以用“优雅”这个词来形容一组好的程序，好程序其实没有特定的标准，以下几点是笔者个人的经验，与大家共享：

1. 关注代码的可读性：可读性的关键在于组件、变量及过程的命名。好的命名让代码读起来像一篇文章，易于理解。像本游戏中对计时器的命名，在笔者自己开发这个程序时，用的名称是计时器1和计时器2，这就不是一种好的命名，在开发到结尾阶段时，连我自己都会发懵。因此在撰写这篇文章时，将计时器1命名为闪现计时器，将计时器2命名为游戏计时器。
2. 关注程序的结构：从图1- 66中我们可以直观地体会什么是结构。像这样在事件处理程序中直接改写变量值或组件属性的做法，当程序足够庞大时，会给代码的维护带来很大的麻烦。就App Inventor开发的程序而言，比较好的做法是，让事件处理程序调用某个过程，让过程来改写变量或属性的值。
3. 小心对待写操作：对组件属性和变量的值有两种操作——读和写。这两种操作中，写操作是不安全的。如果一组程序中有多处代码对同一个变量进行写操作，那么这个变量会像一颗潜伏的炸弹，随时有引爆的危险。好的办法是，减少写操作入口，必要时可以绘制变量的状态图，标出所有的写操作，以便纠错或优化程序。

我们对现有程序作如下两项改进：

1. 改造屏幕初始化事件处理程序：只调用创建按钮列表及游戏初始化两个过程；
2. 去除重复调用：在要素关系图中，游戏计时器组件汇聚了三个箭头，应该减为两个箭头，因为对计时器的设置只有两种可能：①启用计时，②终止计时。启用计时在游戏初始化过程中执行，终止计时在游戏计时程序以及游戏结束过程中执行，而游戏计时程序又调用了游戏结束过程，这相当于终止计时被执行了两次。因此可以删除前者对终止计时的设置，这样指向游戏计时的箭头就剩下两个了。

我们重新绘制改进之后的要素关系图，如图1- 67所示。

图1- 67 程序改进之后的要素关系图