Domain specific warnings: Are they any better?

Tools to detect coding standard violations in source code are commonly used to improve code quality. One of their original goals is to prevent bugs, yet, a high number of false positives is generated by the rules of these tools, i.e., most warnings do not indicate real bugs. There are empirical evidences supporting the intuition that the rules enforced by such tools do not prevent the introduction of bugs in software. This may occur because the rules are too generic and do not focus on domain specific problems of the software under analysis. We underwent an investigation of rules created for a specific domain based on expert opinion to understand if such rules are worthwhile enforcing in the context of defect prevention. In this paper, we performed a systematic study to investigate the relation between generic and domain specific warnings and observed defects. From our experiment on a real case, long term evolution, software, we have found that domain specific rules provide better defect prevention than generic ones.

[1]  Oscar Nierstrasz,et al.  Domain-Specific Program Checking , 2010, TOOLS.

[2]  Murray Hill,et al.  Lint, a C Program Checker , 1978 .

[3]  Andreas Zeller,et al.  When do changes induce fixes? , 2005, ACM SIGSOFT Softw. Eng. Notes.

[4]  Claes Wohlin,et al.  Experimentation in software engineering: an introduction , 2000 .

[5]  Junfeng Yang,et al.  Correlation exploitation in error ranking , 2004, SIGSOFT '04/FSE-12.

[6]  Ralph E. Johnson,et al.  A Refactoring Tool for Smalltalk , 1997, Theory Pract. Object Syst..

[7]  Leon Moonen,et al.  Assessing the value of coding standards: An empirical study , 2008, 2008 IEEE International Conference on Software Maintenance.

[8]  Elliot Soloway,et al.  Where the bugs are , 1985, CHI '85.

[9]  Stefan Wagner,et al.  An Evaluation of Two Bug Pattern Tools for Java , 2008, 2008 1st International Conference on Software Testing, Verification, and Validation.

[10]  Yuanyuan Zhou,et al.  Have things changed now?: an empirical study of bug characteristics in modern open source software , 2006, ASID '06.

[11]  W. Basalaj,et al.  Correlation between coding standards compliance and software quality , 2005 .

[12]  Sunghun Kim,et al.  Memories of bug fixes , 2006, SIGSOFT '06/FSE-14.

[13]  Greg Nelson,et al.  Extended static checking for Java , 2002, PLDI '02.

[14]  Marco Tulio Valente,et al.  Static correspondence and correlation between field defects and warnings reported by a bug finding tool , 2011, Software Quality Journal.

[15]  Leon Moonen,et al.  Evaluating the relation between coding standard violations and faultswithin and across software versions , 2009, 2009 6th IEEE International Working Conference on Mining Software Repositories.

[16]  David Hovemeyer,et al.  Finding bugs is easy , 2004, SIGP.

[17]  David Hovemeyer,et al.  Using Static Analysis to Find Bugs , 2008, IEEE Software.

[18]  Dawson R. Engler,et al.  Checking system rules using system-specific, programmer-written compiler extensions , 2000, OSDI.

[19]  Andreas Zeller,et al.  Mining version archives for co-changed lines , 2006, MSR '06.

[20]  Stéphane Ducasse,et al.  Seaside: A Flexible Environment for Building Dynamic Web Applications , 2007, IEEE Software.

[21]  Audris Mockus,et al.  Identifying reasons for software changes using historic databases , 2000, Proceedings 2000 International Conference on Software Maintenance.

[22]  Thomas Zimmermann,et al.  Automatic Identification of Bug-Introducing Changes , 2006, 21st IEEE/ACM International Conference on Automated Software Engineering (ASE'06).

[23]  Marco Tulio Valente,et al.  Study on the relevance of the warnings reported by Java bug-finding tools , 2011, IET Softw..

[24]  Michael D. Ernst,et al.  Which warnings should I fix first? , 2007, ESEC-FSE '07.