一、实验思路

      分别对bug_intro的commit与bug_fix的commit进行soanr扫描，分别得到对应的sonar的issue结果表，对每条引入buggy的line与产生sonar_issue的line进行匹配，如果行数重合，那就说明这个文件中bug与sonar_issue发生了同现的关系，在bug_fix的commit中再用sonar进行扫描如果发现sonar_issue与bug一起消失掉了，我们把这种现象认为是代码质量与bug是存在关系的

二、初步试验结果

      目前主要是java跑了五个项目，python跑了四个项目，基于目前的结果我们发现:

1)java 项目一共有1411个bug，其中随着和bug一起消失的sonar_issue有275个，比例达到了20%，其中对这种issue进行分类排序后发现如下现象：

1、convention 193(代码编码习惯：比如命名规则，驼峰状的命名规则)

2、brain-overload 181（方法的时间复杂度）

3、design 175（代码的设计：主要是一些类的设计）

4、pitfall  97（代码逻辑缺陷：比如空指针错误）

5、error-handing,security 95(代码中的异常处理等)

java项目的sonar中的代码规则比较多与详细，基于如此的结果可以发现代码复杂度过高，逻辑设计错误，异常处理不正确往往与bug同时出现

2）python项目中主要是有2342个bug出现，bug与sonar_issue一起消失的数量有328个，比例达到了14%，其中对这些issue分类排序发现以下结果：

1、brain-overload 210（方法的时间复杂度）

2、convention 110 （代码编码规范）

3、performance 87 （）

4、confusing 85（代码方法，变量命名不能混淆）

5、obsolete 52 

基于以上的数据可以发现，方法复杂度过高与bug 同现的次数比较大，但由于soanr对python语言的支持不是那么好，所以现有的数据比较少

三、意见

这两天分别听取了王涛师兄与余跃师兄的意见，还有很多需要改进的地方，比如实验的方法，对具体代码行数的sonar issue判断是否准确，还有issue 与buggy中的关系到底如何定义，最后需要对bug分类来验证这个bug是否真的与sonar_issue相关等等

四、后序展望

目前的展望还是要对实验进行改进，我觉得目标应该是发现一种关系当某些issue被sonar扫描出来是，需要引起开发者注意，因为这种issue会有比较大的可能性去引发bug，现在主要的结果还是发现了一些issue与bug的同现概率比较大，具体的下一步思路，还需要和师兄们多多讨论