系统 C#代码开发规范说明书
16、 不在代码中使用具体的路径和驱动器名,使用相对路径,并使路径可编程。永远别
设想你的代码是在“C:”盘运行。你不会知道,一些用户在网络或“Z:”盘运行程序。........16
17、 应用程序启动时作些“自检”并确保所需文件和附件在指定的位置。必要时检查数据
库连接。出现任何问题给用户一个友好的提示。如果需要的配置文件找不到,应用程序
需能自己创建使用默认值的一份。如果在配置文件中发现错误值,应用程序要抛出错误,
给出提示消息告诉用户正确值。错误消息需能帮助用户解决问题。永远别用象“应用程序
出错”,“发现一个错误”等错误消息。而应给出象“更新数据库失败,请确保登陆 ID 和密
码正确。” 的具体消息。显示错误消息时,除了说哪里错了,还应提示用户如何解决问
题。不要用象“更新数据库失败。”这样的,要提示用户怎么做:“更新数据库失败,请确
保登陆 ID 和密码正确。”..........................................................................................................16
18、 显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来,以助诊断问
题。............................................................................................................................................16
19、 注释。别每行代码,每个声明的变量都做注释。在需要的地方注释。可读性强的代
码需要很少的注释,如果所有的变量和方法的命名都很有意义,会使代码可读性很强并
无需太多注释。行数不多的注释会使代码看起来优雅。但如果代码不清晰,可读性差,
那就糟糕。如果因为某种原因使用了复杂艰涩的原理,为程序配备良好的文档和重分的
注释。对一个数值变量采用不是 0,-1 等的数值初始化,给出选择该值的理由。简言之,
要写清晰,可读的代码以致无须什么注释就能理解。对注释做拼写检查,保证语法和标
点符号的正确使用。.................................................................................................................16
20、 异常处理...........................................................................................................................17
21、 不必在所有方法中捕捉一般异常,不管它,让程序崩溃。这将帮助你在开发周期发
现大多数的错误。你可以用应用程序级(线程级)错误处理器处理所有一般的异常。遇
到“意外的一般性错误”时,此错误处理器应该捕捉异常,给用户提示消息,在应用程序
关闭或用户选择“忽略并继续”之前记录错误信息。不必每个方法都用 TRY-CATCH。当特定
的异常可能发生时才使用。比如,当你写文件时,处理异常 FILEIOEXCEPTION。别写太
大的 TRY-CATCH 模块。如果需要,为每个执行的任务编写单独的 TRY-CATCH 模块。这将
帮你找出哪一段代码产生异常,并给用户发出特定的错误消息如果应用程序需要,可以
编写自己的异常类。自定义异常不应从基类 SYSTEMEXCEPTION 派生,而要继承于
IAPPLICATIONEXCEPTION。........................................................................................................18
4 / 18