有10种方式可以搞砸你的代码

mine

写代码是一个富有创意但又可能让人思想麻痹的任务，不管你是否喜欢你的工作，你总会找一些捷径，但遗憾的是，大部分捷径都违反了最佳编码实践原则，这些捷径要么会产生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、就我一个人开发，我只写代码，文档就免了

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

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

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

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

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