猫史档案馆

每当看到程序正确运行的那一刻，你总会很惊讶。

是的，编写程序并不是一个很容易的事情，甚至像Python、C++等语言还不能写错任何一个符号！

虽然scratch、blocky等这类积木式、图形化没有很严格的语法要求，但是如果要求程序完全写正确，也需要掌握一些方法。

方法一：注意数据类型错误。

之前已经说过，scratch的数据均会被保存为字符串。因此当使用变量时，要格外小心数据类型的问题。例如：

因为移动积木需要的参数为整数或浮点数，所以移动字符串并没有任何意义，scratch只会跳过这块积木。

无穷数值确实是特殊的浮点数，但是移动正无穷也没有任何意义，scratch执行后角色位于（273,NaN）的位置上，无法解释的结果……

数字+字符串？结果为数字。但是数字+字符串也没有直观上的意义。

布尔+布尔？真为1假为0。

方法二：命名规范。

无论是角色名、造型名、消息、变量、列表、自定义积木还是参数。这里不再举例。

方法三：防御性编程。

这是一种很好的编程习惯，实践中有很多小技巧，根据经验遇到问题的代码，然后插入一个环境，一旦出现问题告知开发者或进行处理，从而防御不合理的情形，保护后面程序的正确性。在scratch中最常见的形式是检查数据特性情况，排除不合理的数据，避免程序出现BUG。

是不是有一点蒙？

我们来看看实例：

就像上面的一段脚本↑↑↑

如果我们不检测回答是否为偶数，则下面的脚本可能会出现BUG。所以避免程序出现BUG，我们需要保护后面程序的正确性，而排除掉不合理的数据，也就是奇数。

方法四：代码审查。

代码审查是指开发者或用户编写的代码，检查点包括命名规范、程序架构、代码重复、程序可读性、程序扩展性等，提高代码质量，减少BUG出现的可能性。以上问题在“学会游戏设计”章都有讲过。代码审查也是一种编程习惯，我们的目标就是脚本像小说一样朗朗上口。写上注释也是一个好习惯，不然自己看得懂代码，别人看自己写的代码又像看天书，过了一两个礼拜后连自己也忘记了为啥脚本要这样写，可就不好了。

如果你加入了scratch社区，举办定期的脚本互评也是好办法。

方法五：测试。

测试，就是检测程序是否正确运行。但是，测试并不是写完整个程序后才测试程序，而是每一步都需要点击开始测试。因为如果整个程序写完后才测试程序，就算程序出现BUG你也很难发现BUG出在哪里。

测试还分为正确性测试、稳定性测试、效率测试等等；测试还可以分为黑盒测试、白盒测试。

正确性测试是指程序是否正确，稳定性测试是指面对用户的各种输入，程序是否稳定，而效率测试是指程序运行的效率是否高。

黑盒测试只关注整体，白盒测试关注细节。

下面通过一个案例来解释。

显然，我们可以生成1个1，可以生成2个123，也可以生成1个“我喜欢scratch”等等数据。

那如果我想生成0个1呢？

我们称0和1为测试用例。

如果测试用例为-1和“我喜欢scratch”呢？

如果空位是变量，变量是字符串怎么办？

……（n个问号）

既然黑盒测试不好使，那我们就看看白盒测试：

如果你读懂了前面的文字，那你就会发现，这里根本没有任何防御性的程序，

从而导致黑盒测试失败。

方法六：契约式设计。

契约，就是大家都要遵守的规则。那么如果你设定好了契约，你就不用担心上面的测试用例的问题了。

虽然看似有点不负责，但你已经设定好了契约，干嘛还要逼迫自己编写检查参数的程序呢？

例如之前说过的移动无穷步，为什么程序会出错，是因为你破坏了这个积木的契约，这个积木的契约就是步数不能是无穷数值或字符串，如果出错就是你的责任。

契约式设计非常流行，尤其是那些弱类型编程语言（如scratch、python等）。