Cited Beller et al.

This commit is contained in:
Andy Ko 2019-04-30 11:15:53 -07:00
parent cfda14449f
commit caac3d2b36

View file

@ -32,6 +32,7 @@
Somewhere in its implementation there's a line of code, or multiple lines of code, that, given a particular set of inputs, causes the program to fail.
How do you find those defective lines of code?
You debug, and when you're doing debugging right, you do it systematically (<a href="#zeller2">Zeller 2009</a>).
And yet, despite decades of research and practice, most developers have weak debugging skills, don't know how to property use debugging tools, and still rely in basic print statements (<a href="#beller">Beller et al. 2018</a>).
</p>
<h2>Finding the defect</h2>
@ -95,6 +96,7 @@
<small>
<p id="aranda">Jorge Aranda and Gina Venolia. 2009. <a href="http://dx.doi.org/10.1109/ICSE.2009.5070530">The secret life of bugs: Going past the errors and omissions in software repositories</a>. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 298-308.</p>
<p id="beller">Beller, M., Spruit, N., Spinellis, D., & Zaidman, A. (2018, May). <a href="https://doi.org/10.1145/3180155.3180175">On the dichotomy of debugging behavior among programmers</a>. In 2018 IEEE/ACM 40th International Conference on Software Engineering (ICSE) (pp. 572-583).<p>
<p id="bettenburg">Nicolas Bettenburg, Sascha Just, Adrian Schr&oumlter, Cathrin Weiss, Rahul Premraj, and Thomas Zimmermann. 2008. <a href="http://dx.doi.org/10.1145/1453101.1453146">What makes a good bug report?</a> In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering (SIGSOFT '08/FSE-16). ACM, New York, NY, USA, 308-318.</p>
<p id="gilmore">Gilmore, D. (1991). <a href="http://www.sciencedirect.com/science/article/pii/000169189190009O">Models of debugging</a>. Acta Psychologica, 78, 151-172.</p>
<p id="ko">Andrew J. Ko and Brad A. Myers. 2008. <a href="http://dx.doi.org/10.1145/1368088.1368130">Debugging reinvented: asking and answering why and why not questions about program behavior</a>. In Proceedings of the 30th international conference on Software engineering (ICSE '08). ACM, New York, NY, USA, 301-310.</p>