Editing Code review (section)

== Efficiency and effectiveness ==

Ongoing research by Capers Jones analyzing over 12,000 software development projects found formal inspections had a latent defect discovery rate of 60-65%, while informal inspections detected fewer than 50% of defects. The latent defect discovery rate for most forms of testing is about 30%.<ref name="jones08">{{cite web | title=Measuring Defect Potentials and Defect Removal Efficiency | first=Capers | last=Jones | publisher=Crosstalk, The Journal of Defense Software Engineering | date=June 2008 | url=http://www.crosstalkonline.org/storage/issue-archives/2008/200806/200806-0-Issue.pdf | access-date=2010-10-05 | archive-url=https://web.archive.org/web/20120806092322/http://www.crosstalkonline.org/storage/issue-archives/2008/200806/200806-0-Issue.pdf | archive-date=2012-08-06 | url-status=dead }}</ref><ref>{{cite journal|title=Embedded Software: Facts, Figures, and Future | journal=Computer | volume=42 | issue=4 | pages=42–52 | first1=Capers | last1=Jones | first2=Christof | last2=Ebert | date=April 2009 | doi=10.1109/MC.2009.118 | s2cid=14008049 }}</ref> A code review case study published in the book ''Best Kept Secrets of Peer Code Review'' contradicted the Capers Jones study,<ref name="jones08" /> finding that lightweight reviews can uncover as many bugs as formal reviews while being more efficient in terms of cost and money<ref>{{cite book | author = Jason Cohen | title = Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.) | publisher = Smart Bear Inc. | year = 2006 | isbn = 978-1-59916-067-2 | url-access = registration | url = https://archive.org/details/bestkeptsecretso00jaso }}</ref>

Studies indicate that up to 75% of code review comments affect software evolvability and maintainability rather than functionality,<ref name="czerwonka2015 ">{{cite book | doi=10.1109/ICSE.2015.131 | url=https://www.michaelagreiler.com/wp-content/uploads/2019/02/Code-Reviews-Do-Not-Find-Bugs.-How-the-Current-Code-Review-Best-Practice-Slows-Us-Down.pdf | access-date=2020-11-28 | volume=2 | pages=27–28 | year=2015 | last1=Czerwonka | first1=Jacek  | last2=Greiler | first2=Michaela | last3=Tilford | first3=Jack | title=2015 IEEE/ACM 37th IEEE International Conference on Software Engineering | chapter=Code Reviews do Not Find Bugs. How the Current Code Review Best Practice Slows Us Down | isbn=978-1-4799-1934-5 | s2cid=29074469 }}</ref><ref>{{cite journal |doi=10.1109/TSE.2008.71 | citeseerx=10.1.1.188.5757 | url=http://lib.tkk.fi/Diss/2009/isbn9789512298570/article5.pdf | access-date=2012-03-21| title=What Types of Defects Are Really Discovered in Code Reviews? | journal=IEEE Transactions on Software Engineering | volume=35 | issue=3 | pages=430–448 | year=2009 | last1=Mantyla | first1=M.V. | last2=Lassenius | first2=C. | s2cid=17570489 }}</ref><ref name="bacchelli2013icse">{{cite web|title=Expectations, outcomes, and challenges of modern code review | first1=A| last1=Bacchelli| first2=C| last2=Bird|  publisher= Proceedings of the 35th IEEE/ACM International Conference On Software Engineering (ICSE 2013)| date=May 2013| url=http://sback.it/publications/icse2013.pdf | access-date=2015-09-02}}</ref><ref>{{cite web|title=Modern code reviews in open-source projects: which problems do they fix? | first1=M| last1=Beller| first2=A| last2=Bacchelli| first3=A| last3=Zaidman| first4=E| last4=Juergens|  publisher= Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014)| date=May 2014| url=http://sback.it/publications/msr2014.pdf | access-date=2015-09-02}}</ref> suggesting that code reviews are an excellent tool for software companies with long product or system life cycles.<ref>{{cite web | title=Does the Modern Code Inspection Have Value? | first1=Harvey | last1=Siy | first2=Lawrence | last2=Votta | url=http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf | date=2004-12-01 | access-date=2015-02-17 | website=unomaha.edu | url-status=dead | archive-url=https://web.archive.org/web/20150428192217/http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf | archive-date=2015-04-28 }}</ref> Therefore, less than 15% of issues discussed in code reviews relate directly to bugs.<ref name="bosu2015msr">{{cite web |title=Characteristics of Useful Code Reviews: An Empirical Study at Microsoft | first1=Amiangshu| last1=Bosu | first2=Michaela | last2=Greiler | first3=Chris | last3=Bird |   publisher= 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories | date=May 2015| url=https://www.michaelagreiler.com/wp-content/uploads/2019/02/Characteristics-Of-Useful-Comments.pdf | access-date=2020-11-28}}</ref>

=== Guidelines ===

Research indicates review effectiveness correlates with review speed. Optimal code review rates range from 200 to 400 lines of code per hour.<ref name="Kemerer 2009">{{cite journal|last1=Kemerer|first1=C.F.|last2=Paulk|first2=M.C.|title=The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data|journal=IEEE Transactions on Software Engineering|date=2009-04-17|volume=35|issue=4|pages=534–550|doi=10.1109/TSE.2009.27|hdl=11059/14085 |s2cid=14432409|hdl-access=free}}</ref><ref>{{cite web|title=Code Review Metrics|url=https://www.owasp.org/index.php/Code_Review_Metrics#Inspection_Rate|website=Open Web Application Security Project|access-date=9 October 2015|archive-url=https://web.archive.org/web/20151009202719/https://www.owasp.org/index.php/Code_Review_Metrics|archive-date=2015-10-09}}</ref><ref>{{cite web|title=Best Practices for Peer Code Review|url=http://smartbear.com/all-resources/articles/best-practices-for-peer-code-review/|website=Smart Bear|publisher=Smart Bear Software|access-date=9 October 2015|archive-url=https://web.archive.org/web/20151009202810/http://smartbear.com/all-resources/articles/best-practices-for-peer-code-review/|archive-date=2015-10-09}}</ref><ref name="Bisant 1989">{{cite journal|last1=Bisant|first1=David B.|title=A Two-Person Inspection Method to Improve Programming Productivity|journal=IEEE Transactions on Software Engineering|date=October 1989|volume=15|issue=10|pages=1294–1304|doi=10.1109/TSE.1989.559782|s2cid=14921429|url=http://dl.acm.org/citation.cfm?id=77604|access-date=9 October 2015|url-access=subscription}}</ref> Inspecting and reviewing more than a few hundred lines of code per hour for critical software (such as safety critical [[embedded software]]) may be too fast to find errors.<ref name="Kemerer 2009" /><ref>{{cite web|title=A Guide to Code Inspections | first=Jack | last=Ganssle | publisher= The Ganssle Group | date=February 2010 | url=http://www.ganssle.com/inspections.pdf | access-date=2010-10-05}}</ref>

=== Supporting tools ===

[[Static code analysis]] software assist reviewers by automatically checking source code for known vulnerabilities and defect patterns, particularly for large chunks of code.<ref>{{Cite book | doi=10.1109/ICSE.2013.6606642 | isbn=978-1-4673-3076-3 | chapter=Reducing human effort and improving quality in peer code reviews using automatic static analysis and reviewer recommendation | title=2013 35th International Conference on Software Engineering (ICSE) | pages=931–940 | year=2013 | last1=Balachandran | first1=Vipin | s2cid=15823436 }}</ref> A 2012 study by VDC Research reports that 17.6% of the embedded software engineers surveyed currently use automated tools to support peer code review and 23.7% plan to use them within two years.<ref>{{cite web|title=Automated Defect Prevention for Embedded Software Quality | last=VDC Research| publisher = VDC Research| date=2012-02-01 | url=http://alm.parasoft.com/embedded-software-vdc-report/ | access-date=2012-04-10}}</ref>