2010年十二月月 发布的文章

基于svn diff结果的有效代码量统计

很多公司的过程中都有阶段性统计新增或修改的有效代码行数这一环节,这里先不论统计出的结果用于做什么,就统计本身而言,常常存在诸多问题,比如统计过程耗时且繁琐、统计结果中估算成分较大,不精确等。这些问题以前也一直困扰着我们,并且长时间没有想出很好的解决办法。

今天脑子里突然冒出一个想法:能否根据svn diff得到的结果分析出来有效代码量呢? svn diff的结果一般是这样的,分为几类:

纯新增代码,如:
+void foo() {
+    … …
+}

纯删除代码,如:
-void foo() {
-    … …
-}

修改的代码,如:
-void foo(void);
+void foo(int);

我们所要统计的所谓有效代码更多是指纯新增的代码和修改的代码,纯删除的代码可忽略不计。这样一来实际有效代码行数 = 纯新增代码行数 + 修改代码行数;而修改的代码在svn diff结果中体现为一减一加,实际修改行数是等于其+的行数的。也就是说有效代码行数就是svn diff结果中所有前缀为+的行的行数。svn diff输出格式相对规整,通过解析得到这个行数并非难事。最简单的方法就是使用Shell脚本了。

脚本全部内容这里就不列出来了,这里可以下载。其核心代码只有以下两行:

svn diff -r$start_revision:$end_revision $target $USERNAME $PASSWD > $TEMPFILE
add_lines_count=`grep "^+" $TEMPFILE|grep -v "^+++"|sed 's/^.//'|sed '/^$/d'|wc -l`

首先我们使用svn diff命令将两个修订号之间的差异重定向到一个临时文件中,然后使用grep、sed和wc的组合完成行数的计算:其中首先过滤出以+开头的行,但去除其中+++开头的行,得到的是所有只以一个+开头的行。再利用set 's/^.//'删除每行行首的那个+,用set '/^$/d'删除所有空行,最后利用wc -l计算总行数。

也就是说通过上面脚本运行后得到的有效代码行数是不包括空行的,但是包含注释代码。

有了这个脚本,以后的版本有效代码量统计就相当精确了,而且也无需每个人都参与统计,大大减少了工作量,甚至可以将这个工作做成自动化完成。

现在的我痛恨一切效率低下的个人行为和过程活动!遇到问题坚决改善,绝不姑息^_^。

关于在线代码评审的几点考量

记得上次折腾Review Board这个在线代码评审工具还是在一年前,那时的Review Board版本是1.0.3;这周部门的一位同事也在折腾Review Board,不过现在的版本已经升级到了1.5.1了。新版Review Board显然修正了许多旧版本中存在的问题,另外无法支持ssl邮件端口的问题也被我这位同事通过更换django源文件的方式搞定了。Review Board好用了,下一步需要关注的就是怎样才能用好Review Board的问题了。

一般认为代码评审是一项优秀的软件开发实践,它可以将很多隐患和bug消灭在萌芽阶段。其实践形式大致有代码走查、代码审查和结对编程(每时每刻都在做代码评审)这三种。一般来说读懂别人的代码可能比自己亲自编写代码花费的时间还要长,而且更为困难,所以除了结对编程之外,代码走查和审查都是低效的,多数情况下都是高投入低产出的,引入在线评审恰恰是对这些低效代码评审形式的一个有效补充,另外在线评审更适合异地团队和开源项目。

那么什么情况下适合发起在线Code Review Request呢?可考虑下面几种情况:
- 新增的关键功能代码的评审
- 系统改善或优化代码的评审
- bugfix代码的评审
- 一些试验性代码的可行性评审

创建一个新的Review request时应考虑注意以下几点:
- 精确描述review request,提供此次评审的重要关注点;
- 每个review request要有针对性,选择合适的评审人,不要泛泛的发给所有人;
- 明确此次评审的截止时间点;
- 每个review request所包含的待评审代码的行数最好不要超过50行,以30行以内为佳。如果你的request中包含了上千行的代码,我想是没人会去真正评审你的代码的。

在项目编码高峰期,切忌发起大量在线Review request,那样的话,大家都会"淹没"在诸多Requests中,评审质量会严重下降,评审人的热情也会受到打击^_^。这个时候我们可以考虑结合其他评审方式,如采用结对和走查。另外对于一些遗留的维护项目,由于代码历史较为"悠久",相关干系人较多,无法确认的因素也较多,可通过在线评审方式将review request发给相关干系人,以获得全面的评审,避免死角。

以上是目前关于在线代码评审的一些考量,这里记之以备忘。

"%05s"行为未定义

下班前,一位同事发来的mail中提到这样一个问题:在Solaris上,新添加到Project中的一段代码编译有Warning,由于我们在Makefile的GCC命令行中设置了"视警告如错误"的-Werror编译选项,导致了项目无法成功Build。

这个Warning内容如下:
warning: `0' flag used with `%s' printf format

产生这个Warning的那行代码大致是类似这样的:printf("%05s%06s\n", "11", "222"); 其实这段代码是从老项目中Copy出来的,在老项目中,这段代码运行的很是正常,也许它在老项目Build时也会产生Warning,不过之前大家也都没有关注。

这个Warning我以前还真未遇到过,代码看起来写的也没有问题,我在Ubuntu 10.04(GCC 4.4.3)上测试了一下这段代码,同样产生了Warning。不过执行一下编译后的程序,我发现了问题。显然这段代码的意图是想通过"%05s"这样的格式控制串来达到自动补0的目的,但是Ubuntu下输出的结果却与此预期相悖–没有补0,补的是空格。我又拿同样的代码在Solaris(Solaris 10 for x86, gcc 3.4.6)上试了一下,虽然也有Warning,但结果和预期是相符的。

这个问题显然比我预期的严重:一段代码在两个平台上产生了不同的行为,问题显然出在"%05s"的使用上。翻开《C语言参考手册》找到输入/输出函数一章,在"输出转换说明"一表中可与s转换搭配的只有'-标志',没有'0标志',但手册里并未明确说明如果将0标志与s转换结合会有什么后果。又Google了一下,发现一些资料里提到在printf系列接口中使用类似"%5s"这样的格式控制串的行为是未定义的,和我试验的结果一致。

考虑到可移植性,"%05s"这样的格式控制串不能再继续使用了,替代方法有多种,这里就不赘述了。如果你的代码里也有使用类似"%05s"这种格式控制串,那赶紧想办法替换掉吧,除非你的代码一直跑在Solaris上。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多