开发的技术规范与实践

1 ASP Net 平台开发的技术规范与实践精华总结平台开发的技术规范与实践精华总结 本言语是以下是本人对 Net 平台开发实践的一些点滴总结 这里的技术规范主要是开 发过程的代码规范 数据库设计规范 Com 和 Net 互操作规范 实践精华是对技术实践过 程中的部分总结 一 代码规范一 代码规范 良好的代码风格来自于同一的代码规范 风格良好的代码不仅具备可读性和可维 护性 同时也给人行云流水 赏心悦目之快感 据 Microsoft 公司统计 基于微软平台的开发中 有 70 80 的印度工程师在完成 同类算法或者模块时 使用的代码基本一致 而相同的调查中只有 20 的中国工程师 们是基本一致的 这说明我们的代码生产过程亟待规范 实义命名实义命名 类型 变量 常量 方法等标识符一律采用对应的英文实义 如果涉及到两个独 立的实义单词 则中间用下划线间隔或者单词首字母大写 两种方式都可以 如果标 识符的长度超过了 30 个字母 则基本上以英文单词发音的重读音节取选出三个字母 如 Repeater 用 rpt Management 用 mgt 大小写规则 目前一般有两种大小写规则目前一般有两种大小写规则 Pascal 大小写形式 所有单词第一个字母大写 其他字母小写 Camel 大小写形式 除了第一个单词 所有单词第一个字母大写 其他字母小写 类名使用 Pascal 大小写形式 public class HelloWorld 或者 Hello World 以下同 不再赘述 方法使用 Pascal 大小写形式 public class HelloWorld void SayHello string name 变量和方法参数使用变量和方法参数使用 Camel 大小写形式大小写形式 public class HelloWorld int totalCount 0 void SayHello string name string fullMessage Hello name 不要使用匈牙利方法来命名变量不要使用匈牙利方法来命名变量 2 以前 多数程序员喜欢把数据类型作为变量名的前缀而 m 作为成员变量的前 缀 例如 string m sName int nAge 然而 这种方式在 NET 编码规范中是不推荐的 所有变量都用 Camel 大小写形 式 而不是用数据类型和 m 来作前缀 用 name address salary 等代替 nam addr sal 别使用单个字母的变量象 i n x 等 使用 index temp 等 用于循环迭代的变 量例外 如果变量只用于迭代计数 没有在循环的其他地方出现 允许用单个字母的变量 命名 而不是另外取实义名 文件名要和类名匹配 例如 对于类 HelloWorld 相应的文件名应为 helloworld cs 缩进和间隔缩进和间隔 缩进用 TAB 不用 SPACES 注释需和代码对齐 遵循 VS2005 的自动对齐规则 不要人为的调整 用一个空行来分开代码的逻辑分组 在一个类中 各个方法的实现体必须用空行间隔 大括弧 需独立一行 在每个运算符和括号的前后都空一格 如 If showResult true for int i 0 i 10 i 而不是 if showResult true for int i 0 i 10 i 良好的编程习惯良好的编程习惯 避免使用大文件 如果一个文件里的代码超过 300 400 行 必须考虑将代码分 开到不同类中 避免写太长的方法 一个典型的方法代码在 1 30 行之间 如果一个方法发代码超过 30 行 应该考虑将其分解为不同的方法 方法名需能看出它作什么 别使用会引起 误解的名字 如果名字一目了然 就无需用文档来解释方法的功能了 一个方法只完成一个任务 不要把多个任务组合到一个方法中 即使那些任务非 常小 使用 C 的特有类型 而不是 System 命名空间中定义的别名类型 如 int age string name 3 object contactInfo 而不是 Int16 age String name Object contactInfo 这么做是基于如下两点原因 1 规范性和一致性 2 便于跨语言平台的移 植 别在程序中使用固定数值 用常量代替 别用字符串常数 尽量用资源文件 避 免使用很多成员变量 声明局部变量 并传递给方法 不要在方法间共享成员变量 如果在几个方法间共享一个成员变量 那就很难知道是哪个方法在什么时候修改了它 的值 必要时使用 enum 别用数字或字符串来指示离散值 别把成员变量声明为 public 或 protected 都声明为 private 而使用 public protected 的 Properties 不在代码中使用具体的路径和驱动器名 使用相对路径 并使路径可编程 永远 别设想你的代码是在 C 盘运行 你不会知道 一些用户在网络或 Z 盘运行程序 应用程序启动时作些 自检 并确保所需文件和附件在指定的位置 必要时检查 数据库连接 出现任何问题给用户一个友好的提示 如果需要的配置文件找不到 应用程序需能自己创建使用默认值 如果在配置文 件中发现错误值 应用程序要抛出错误 给出提示消息告诉用户正确值 错误消息需 能帮助用户解决问题 注释注释 别每行代码 每个声明的变量都做注释 在需要的地方注释 可读性强的代码需要很少的注释 如果所有的变量和方法的命名都很有意义 会 使代码可读性很强并无需太多注释 行数不多的注释会使代码看起来优雅 如果因为 某种原因使用了复杂艰涩的原理 必须为程序配备良好的文档和详细的注释 对注释 做拼写检查 保证语法和标点符号的正确使用 二 数据库设计规范二 数据库设计规范 表格分类与命名表格分类与命名 数据表的分类数据表的分类 系统表 支撑业务模型的数据表 如流程模型 系统管理相关表 业务表 产品提供的针对业务的通用功能模块相关表 如通用业务查询等 用户表 用户二次开发使用的与具体业务相关的数据表 数据表的命名数据表的命名 所有表格命名一律以字母 T 开头 Table 并且用实义单词以下划线 间 隔 系统表 系统表前缀为 TSYS 业务表前缀为 TBIZ 用户表由用户自行定义 但是建议不要与系统表和业务表的命名规则重复 字段的命名字段的命名 字段的命名规则参照代码标识符的命名规则 但是注意避开数据库的保留字 比如不要采用这样的字段名 index field password id Oracle SQL 等等 对于涉及到技术核心的系统表 为了防止剖析 建议采用类似 F1 F2 F3 Fn 的方式命名 但是不要采用 F0 因为这个名称在某些 数据库中不被允许 比如 Interbase 4 索引的建立索引的建立 索引是一把双刃剑 索引将提高查询的效率 但是却降低了 insert delete update 的效率 通常情况下 对数据的编辑频度和时限要求远远低于对数据库的查询要求 因此 对于记录很多且频繁查询的数据表 必须建立索引 大多数数据库为主键字段自动创建索引 注意为外键创建索引 不要索引大字段 这样作会让索引占用太多的存储空间 尽量不要索引频繁编辑的小型表 identify 字段不要作为表的主键与其它表关联 这将会影响到该表的数据迁移 如果考虑支持多数据库 建议主键采用程序生成的唯一值 如果一个大型表需要频繁的做 insert delete update 操作 同时也需 要做高并发量的查询 那么建议根据数据的访问频度对表作拆分 而后建立索引 过程与函数过程与函数 数据库厂商为了凸现自身的优势 都提供了丰富且个性化的过程与函数 为了提升产品的伸缩性和数据无关性 请不要使用与特定数据库相关的过程与函 数 也不推荐采用 Store Procedure 建议使用应用服务器的中间层业务对象 字段字段 域的定义域的定义 尽量避免使用 Blob 如果一定要用 请不要索引 blob 并且不要定义多个 blob 不要使用日期字段 改用字符串 char 19 替代 如 2008 12 09 12 22 08 对于确定长度的串 请固定字段类型的长度 如 char 80 不要采用 varchar 对于值类型字段 请使用对应的数据库值类型 而不要用字符串 三 三 Com 和和 Net 互操作规范互操作规范 NET 技术已经成为微软平台的主流 但是在 Win32 时代开发了很多 COM DCOM 组件 由于在开发 COM 组件时投入了大量的人力 财力 如何在 NET 环境下重用这些 COM 组件就显得更有意义 NET 支持运行时通过 COM COM 本地 WinAPI 调用与未托管代码的双向互操作 性 要实现互操作性 必须首先引入 NET Framework 的 System Runtime InteropServices 命名空间 C 的语法为 using System Runtime InteropServices 1 NET 访问访问 API NET 允许 C 访问未托管的 DLL 的函数 如要调用 Windows User32 dll 的 MessageBox 函数 int MessageBox HWND hwnd LPCTSTR lpText LPCTSTR lpCaption UINT uType 可以声明一个具有 DLLImport 属性的 static extern 方法 using System Runtime InteropServices DllImport user32 dll static ertern int MessageBox int hwnd string text string caption int type 然后在代码里面直接调用就可以了 这里要注意在调用返回字符串的 API 中使用 StringBuilder 对象 2 NET 访问访问 COM 组件组件 5 从 NET 调用 COM 组件比较容易 只要使用 tlbimp exe 产生 COM 的装配形 式的 WarpClass 然后在 NET 项目中调用即可 注意 COM 的类型信息通过 Type Library 文件描述 NET 装配件是自描述的 Tlbimp 的作用是从 COM 组件及其类型信息中产生自描述的装配件 1 编写 Com 组件 编译生成一个 ComAccount dll 2 产生 NET 可访问的包装类 assembly 使用 TlbImp exe 产生 NET 装配件 TlbImp out NetAccount dll ComAccount dll 3 在 在 NET 代码中访问代码中访问 NET 代码只需引用 NetAccount dll 就可以像访问 NET 的装配件一样访问 COM 组件 四 异常处理四 异常处理 异常处理的原则异常处理的原则 在应用程序级 线程级 错误处理器中处理所有的一般异常 遇到 意外的 一般性错误 时 此刻错误处理器应该捕捉异常 给用户提示消息 在应用程序 关闭或用户选择 忽略并继续 之前记录错误信息 不必每个方法都用 try catch 当特定的异常可能发生时才使用 比如 当写 文件时 处理异常 FileIOException 别写太大的 try catch 模块 如果需要 为每 个执行的任务编写单独的 try catch 模块 这将有助于找出哪一段代码产生异常 并给用户发出特定的错误消息 如果应用程序需要 可以编写自己的异常类 自 定义异常不应从基类 SystemException 派生 而要继承于 IApplicationException 在开发阶段 不必在所有方法中捕捉一般异常 刻意的放纵异常 将帮助在 开发周期发现大多数的错误 异常处理的提示异常处理的提示 不要捕捉了异常却什么也不做 看起来系统似乎在正常运行 如果这样隐藏 了一个异常 将永远不知道异常到底是否发生 为什么发生 发生异常时 给出 友好的消息给用户 但要精确记录错误的所有可能细节 包括发生的时间 和相 关方法 类名等 永远别用像 应用程序出错 发现一个错误 等错误提示消 息 而应给出类似 更新数据库失败 请确保登陆 id 和密码正确 之类的具体 消息 显示错误消息时 还应提示用户如何解决问题 如 更新数据库失败 请确保登陆 id 和密码正确 而不是仅仅说 更新数据库失败 显示给用户的消息要简短而友好 但要把所有可能的信息都记录下来 以助诊断 问题 异常处理的代码实例 推荐如下异常处理模式 void ReadFromFile string fileName try 读文件 catch FileIOException ex 记载异常日志 6 重抛具有针对性的异常信息 throw 不推荐如下的异常处理模式 void ReadFromFile string fileName try 读文件 catch Exception ex 捕捉一般异常将让我们永远不知道到底是文件错误还是其他错误 隐藏异常将我们永远不知道有错误发生 return 五 对象实例的申请与释放五 对象实例的申请与释放 Net 平台的垃圾回收机制 可以自动的 dispose 不再引用的对象实例 所以很 多开发人员并不主动释放申请的对象资源 事实上 在对象的生命周期结束之前 是不会被释放的 但是 很多时候当对象处于生命周期之内时 我们不再使用它 以便释放资源提 升系统效率 因此 主动释放申请的资源显得很有必要 永远不要把力所能及的事情交给操作系统 及时释放不再使用的资源是一个好习 惯 六 数据库访问六 数据库访问 数据库访问永远是系统的瓶颈 选择高效 稳健的数据库访问模式是产品性 能的基础保证 永远不要假设你的应用系统构建与某个数据库之上 因此必须有统一的 透明的 数据库访问机制 采用采用 ADO Net 访问数据库访问数据库 基于效率和稳定性的考量 采用微软平台原生的数据库访问模式 ADO Net 使用 ADO Net 可以通过 OLEDB 和 ODBC 两种模式访问数据库 我们建议使