经验技巧:最佳编码实践之搞砸代码的10种方法

作者Susan Harkins是世界最大的技术期刊出版社的主编,具有多年的实践经验;在这篇文章里她重申“最佳编码实践原则”的重要性;虽然文中主要讨论VB开发相关的东西,但正如作者所说,“虽然其中一部分只适用于VBA或某种IDE,但大多数都是通用的”,希望大家触类旁通,将这些方法实践到自己的开发工作中。

以下是Susan的正文:

写代码是一个富有创意但又可能让人思想麻痹的任务,不管你是否喜欢你的工作,你总会找一些捷径,但遗憾的是,大部分捷径都违反了最佳编码实践原则,这些捷径要么会产生BUG,要么会导致数据出错,我的建议是:在编写VBA代码时,不要走捷径。下面是一些常见的错误观念,导致人们选择了错误的捷径,虽然其中一部分只适用于VBA或某种IDE,但大多数都是通用的。

1、我不需要else子句

If…then…else,select case等VBA语句都包含了else子句,这个子句后跟随了所有具体的决策条件,这是处理一些带条件事情的最好机会,但开发人员却忽略了这个机会,并认为没必要这么做。包括一个else子句并不难,并且还可以提供一层额外的错误捕捉机会,你可以显示一般性错误,让用户知道预期的决定或行动不会发生,或是通过日志记录下来,用电子邮件发送给管理员或内部开发人员,总之想让事件引起注意,一个未执行的else子句比多个选择更好。

2、goto是一个有效的语句,我经常使用它

Goto是一个有效的语句,但使用不当会产生难以驾驭的代码,而且会隐藏错误和拙劣的程序设计,当你不能想出一个更好的策略时,不要轻易使用goto语句,当你真正需要一个简单的重定向程序流时可以使用它,每次敲下goto时都问一下自己,是否有其它方法来处理这个重定向?如果有就不要使用goto(我在VBA开发中就从未使用过goto语句)。

3、编译器是在浪费时间

和其它编译器不同,VBA编译器不会生成一个可以脱离Office独立执行的模块,相反,VBA编译器实际上是一个语法检查器,在真实运行之前,编译你的代码是捕捉语法错误简单有效的方法,你为什么要这么做呢?因为语法检查器通常提供更深入的错误信息,因此你可以更快地解决问题。

4、无任何错误需要处理

大多数开发人员还没有自信到自己的代码是完美无缺的,但大多数人对错误处理都会掉以轻心,错误处理和你的设计和逻辑一样重要,不要放弃它,相反,在处理错误时应当特别小心,一个未处理的错误通常意味着程序投入使用后,你会接到更多的支持电话,也许程序因这个错误而停止了工作,也许它导致了数据异常,在处理错误时,你可以:

◆与你的用户分享一些信息,包括立即纠正错误的说明。

◆帮助程序立即从错误中安静地回复,用户永远也不会知道程序曾经发生了错误。

◆跟踪错误,以便你进行修复。

5、我的用户将输入正确的数据

如果程序正常运行需要依赖用户的准确输入,这将是风险很大的一件事,这不是对用户能力的质疑,用户都不是傻子,但确保程序正常运行并不是他们的本职工作,你不能依赖他们输入正确的数据,相反,你应该从技术上来验证用户的输入,你可以使用表属性从底层来约束和验证,但大多数时候还是要靠你写的代码来验证,这也许是程序基本功能代码完成后最重要的任务,因此不要吝啬你的代码,不能依靠用户不犯错误的输入,你应该坚定地拿起验证程序捕捉错误并纠正它们。

6、认为带前缀或标签的命名约定不好

你在创建一个变量时,能通过数据类型和用途识别它是最好的,大多数VBA开发人员喜欢添加3个字符的前缀,或标签来确定数据类型,例如,用于存储姓氏的字符串数据类型可能命名为strLastName,前缀确定了变量的数据类型,LastName确定了变量的用途,有些开发人员认为这个前缀是没有必要的,甚至会造成干扰,因此他们不使用前缀,在某些情况下,数据类型的确是显而易见的,但有时却不那么明显,添加前缀或标签不会增加工作量,但它的好处却有很多,如:

◆标签是自文档化(self-documenting)的。

◆在调试或修改代码时,你可以立即知道变量的数据类型。

◆在投入生产几个月后,你也许早已记不得那些变量的含义了,或者你已经离开,后来的维护者在前缀或标签的提示下,能更快地读懂代码。

7、不会有任何空值

无论你采取什么措施,空值总是带有破坏性,如果你正确地处理空值,程序将会更稳定,VBA提供几种工具来发现和处理空值。

◆使用IsNull()确定一个表达式或值是否为空,你不能对空值使用比较操作符,如var=Null或var<>Null,直接比较总是返回空(T-SQL有时会返回False)。

◆在Access中,遇到Null时,Nz()返回一个值,而不是Null。

◆如果你需要处理Null变量,请使用Var数据类型,它是唯一可以存储Null的数据类型。

8、我是唯一一个使用应用程序的人,因此我在程序中嵌入了密码

密码和用户id值永远都不应该嵌入到代码中,你可能是唯一被授权使用该应用程序的人,但这并不意味着就可以直接将密码嵌入到程序中,相反,不管是谁要使用这个程序,都应该提供一个对话框让其输入登录凭据。

9、我写代码时就做了测试,不用再测试了

当你写代码时就做了测试,这很好,但这样做是不够的,开发人员通常不适合测试自己写的代码,他们不会把自己想象成用户,因此很难发现重大BUG,往往是走走过场罢了,要知道最终是要把程序投入生产环境,那时就不是你自己使用了,因此应该找一些最终用户来测试。

10、就我一个人开发,我只写代码,文档就免了

如果就你一个开发人员,也许你不会写文档,你认为那只是耽误自己的工作,但大多数开发人员在修改非自己写的代码之前,都希望有良好的文档参考。别的不说,至少下面这些内容应该有文档记录。

◆例行的目的/任务/目标。

◆传递的值和参数的简短定义。

◆对一些非常规的代码写法,附上解释和想法。

◆谁创建的代码,谁在什么时候修改过代码,修改了哪些内容,当你离职后,其他接收的人看到良好的注释一定会从心底敬佩你。