我所在的小组讨论并通过了编码规范, 形成文档, check in到服务器, 给新来的每个员工都打印一份, 前几天不干别的专门看这个.
听起来象是不错的实践方法, 其实不然, 这样的弱约定时间一长根本没人在意, 没人会遵守. 我偶尔做一次code review就会发现项目组内部大量违反编码规范的check in.
所以, 只有强制执行的东西才会被真正落实, 此前, 对于向CVS中提交时不加任何注释的情况, 我在CVSROOT目录下的commitinfo 中做了一项配置, 通过一个perl小程序检查为空的注释, 发现这种情况输出如下的错误信息, 强制提交失败, 在这一做法之下, 注释的真正质量虽然不能保证, 但至少从形式上提醒了不加注释提交的人. 至少到目前为止, 对这一条规范, 效果良好, 但编码规范中有太多的其它内容, 其中有一些是可以通过自动化的方式加以识别的. 所以花了一些时间, 将原来零零碎碎的几条规范的检查从perl 小程序转为统一的一个C#程序来做, 原因是:
commitinfo 的格式:
Regex_of_the_directory_name_of_the_file_to_be_checked_in_relative_to_root program_to_run optional_parameters_including_cvs_specifier
一行一条, 一共3部分, 第一部分是一个符合Emacs正则表达式规范的正则表达式, 它匹配的是相对于CVS 根目录的一个路径, 不包括文件名部分, 整个正则表达式也不象 XPath中的正则表达式一样, 隐含地匹配完整的字符串, 它匹配部分内容即为匹配成功, 比如
cvs ci MyProject/dir1/dir2/file1
这样命令, 被匹配的路径部分是 "MyProject/dir1/dir2"(假设 MyProject是仓库root目录下的一级目录), 而"/dir1/" 这样一个正则表达式写在commitinfo 的第一个field中即可成功匹配.
第二部分是个路径名, CVSNT 2.5.03 运行在windows系统上时, "C:/my_program.exe" 这样的unix风格路径分隔符也是接受的, 如果含有空格, 一定要用双引号.
第三部分是可选的参数, 这些参数作为命令行传递给第二部分的程序, cvsnt 提供几个特殊符号: %m 是注释, 其它的也还有几个, 在这不深究
有几个非常重要的问题:
1. 被check in的文件名是通过标准输入传递给检查程序的, 一行一个.
2. 运行检查程序时, 检查程序的当前目录被自动设置在CVSNT配置好的一个临时目录下, 再加上相对路径.
3. 如果客户端在命令行上一交提交的文件分布在不同的子目录中, 有几个不同的子目录就需要运行几次检查程序, 所以尽管客户端的提交命令可能只有一条, 但检查程序却可能被多次运行, 因为每次运行只能有一个当前目录, 这个当前目录必需是被检查的文件所在的目录, 如
cvs ci dir1/file1.cpp dir2/file2.cpp
4. Form1.Designer.cs 中Form Designer所生成的控件的默认变星名, 都是类型名后面加数字(类型名的第一个字母小写). 这是很糟糕的命令规范, 程序员有责任把它改成符合项目规范的名称.
CVSNT配置的临时目录是 D:\CVSTEMP
则检查程序会分别运行两次, 其当前目录是:
1. D:\CVSTEMP\cvs-serv4492\dir1
2. D:\CVSTEMP\cvs-serv4492\dir2
其中 cvs-serv4492 这个部分是每次变化的, CVS为了避免冲突每次生成的.
另一个非常重要的地方是, 检查程序可以假设被提交的文件已经位于CVS服务器上, 象普通的文件一样可以读取其内容, 因为被检查的内容必需是正被提交的内容, 而正被提交的内容在检查通过之前是不能正式放入仓库中的, 所以CVS服务器才采用了上述的方案.
个人感觉是, 用C#写检查程序比用Perl方便很多, 可能是我现在对C#更熟悉的缘故.
已经加入到自动检查程序中的几项是:
1. 对于VC项目
1.1 .vcproj项目配置文件中, 无论Debug还是Release必需保证 Warning Level为4
1.2 无论什么配置下, 必需保证 Warn as error 为true, 即把一切warning 视为error
1.3 不能对Release版本设置项目范围内的 Optimization, 原因这里不讲, 反正这是定论, 默认永远不优化. 对单个文件设置优化是允许的.
1.4 对Release版本必需打开 Code analyze, 这是VS2008中的编译器高级功能, 对查找象warning那么明显的问题之外的潜在错误很有用. 题外话, code analyze很有用, 但我们被迫使用正版的standard 版本之后, 可能就没机会那么方便使用它了.
2. 对于项目中涉及的所有XML, 通过XML schema进行检查, 并进行schema 所不能检查到的一些语义检查. 这个对以XML来管理项目数据的情况太重要了, 无数的bug都是因为有人check in了错误的XML文件造成的.
这一点直接来自另一条XML最佳实践:
对用到的所有XML, 都用Schema进行检查.
如果要补充一点, 那就是在外部数据进入你的程序的入口处进行一次检查, 或在release之前一定检查一遍, 而不是有事没事都到处检查, 检查会拖慢对XML文档的处理. 如果每次LOAD XML文档都要检查, 代价你付不起.
阅读(938) | 评论(0) | 转发(0) |
