Editing Code review

{{short description|Activity where one or more people check a program's code}}
{{Software development process}}
[[File:Pair_Programming_3.jpg | thumb|220x124px | right | Software Engineers ({{Aka}} programmers) reviewing a program]]
'''Code review''' (sometimes referred to as [[Software peer review|peer review]]) is a [[software quality assurance]] activity in which one or more people examine the [[source code]] of a [[computer program]], either after implementation or during the development process. The persons performing the checking, excluding the author, are called "reviewers". At least one reviewer must not be the code's author.<ref name="baum2016qrs">{{cite book |last1=Baum |first1=Tobias |last2=Liskin |first2=Olga |last3=Niklas |first3=Kai |last4=Schneider |first4=Kurt |title= 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS)|pages=74–85 |date=2016 |doi=10.1109/QRS.2016.19|isbn=978-1-5090-4127-5 |chapter=A Faceted Classification Scheme for Change-Based Industrial Code Review Processes |s2cid=9569007 }}</ref><ref name="best_practices">{{cite book | last = Kolawa | first = Adam |author2=Huizinga, Dorota | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page=260 | isbn = 978-0-470-04212-0 }}</ref>

Code review differs from related [[software quality assurance]] techniques like [[static code analysis]], [[Rubber duck debugging|self-checks]], [[Software testing|testing]], and [[pair programming]]. Static analysis relies primarily on automated tools, self-checks involve only the author, testing requires code execution, and pair programming is performed continuously during development rather than as a separate step.<ref name="baum2016qrs"/>

== Goal ==
Although direct discovery of quality problems is often the main goal,<ref name="baum2017profes">{{cite book |last1=Baum |first1=Tobias |title=Product-Focused Software Process Improvement |last2=Leßmann |first2=Hendrik |last3=Schneider |first3=Kurt |date=2017 |isbn=978-3-319-69925-7 |series=Lecture Notes in Computer Science |volume=10611 |pages=111–127 |chapter=The Choice of Code Review Process: A Survey on the State of the Practice |doi=10.1007/978-3-319-69926-4_9}}</ref> code reviews are usually performed to reach a combination of goals:<ref name="bacchelli2013icse" /><ref name="baum2016fse">{{cite book |last1=Baum |first1=Tobias |title=Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2016 |last2=Liskin |first2=Olga |last3=Niklas |first3=Kai |last4=Schneider |first4=Kurt |date=2016 |isbn=9781450342186 |pages=85–96 |chapter=Factors Influencing Code Review Processes in Industry |doi=10.1145/2950290.2950323 |s2cid=15467294}}</ref>

* ''Improving code quality'' {{snd}}Improve internal code quality and [[maintainability]] through better readability, uniformity, and understandability
* ''Detecting [[Software bug|defects]]''{{snd}}Improve quality regarding external aspects, especially correctness, but also find issues such as performance problems, security vulnerabilities, and injected malware
* ''Learning/Knowledge transfer''{{snd}}Sharing codebase knowledge, solution approaches, and quality expectations, both to the reviewers and the author
* ''Increase sense of mutual responsibility''{{snd}}Increase a sense of collective [[code ownership]] and solidarity
* ''Finding better solutions''{{snd}}Generate ideas for new and better solutions and ideas beyond the specific code at hand
* ''Complying to QA guidelines, ISO/IEC standards''{{snd}}Code reviews are mandatory in some contexts, such as air traffic software and [[Safety-critical system|safety-critical]] software

== Review types ==

Several variations of code review processes exist, with additional types specified in [[IEEE 1028]].<ref>{{Cite book|title=IEEE Standard for Software Reviews and Audits|publisher=IEEE STD 1028-2008 |date=August 2008 |pages=1–53 |url=https://ieeexplore.ieee.org/document/4601584|doi=10.1109/ieeestd.2008.4601584|isbn=978-0-7381-5768-9 }}</ref>

* Management reviews
* Technical reviews
* Inspections
* Walk-throughs
* Audits

=== Inspection (formal) ===

Historically, the first code review process that was studied and described in detail was called "Inspection" by its inventor, [[Michael Fagan (software designer)|Michael Fagan]].<ref name="fagan1976">{{cite journal |last1=Fagan |first1=Michael |title=Design and code inspections to reduce errors in program development |journal=IBM Systems Journal |date=1976 |volume=15 |issue=3 |pages=182–211|doi=10.1147/sj.153.0182 }}</ref> [[Fagan inspection]] is a formal process that involves a careful and detailed execution with multiple participants and phases. In formal code reviews, [[software developers]] attend a series of meetings to examine code line by line, often using printed copies. Research has shown formal inspections to be extremely thorough and highly effective at identifying defects.<ref name="fagan1976"/>

=== Regular change-based code review (Walk-throughs) ===
Software development teams typically adopt a more lightweight review process in which the scope of each review is on the changes to the codebase performed in a ticket, user story, commit, or some other unit of work.<ref name="rigby2013fse">{{cite book |last1=Rigby |first1=Peter |title=Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering |last2=Bird |first2=Christian |date=2013 |isbn=9781450322379 |pages=202–212 |chapter=Convergent contemporary software peer review practices |citeseerx=10.1.1.641.1046 |doi=10.1145/2491411.2491444 |s2cid=11163811}}</ref><ref name="baum2017profes" /> Furthermore, there are rules or conventions that integrate the review task into the development workflow through conventions like mandatory review of all tickets, commonly as part of a [[pull request]], instead of explicitly planning each review. Such a process is called "regular, change-based code review".<ref name="baum2016qrs"/> There are many variations of this basic process.

A 2017 survey of 240 development teams found that 90% of teams using code review followed a change-based process, with 60% specifically using regular change-based review.<ref name="baum2017profes"/>
Major software corporations known to use changed-based code review include Microsoft,<ref name="macleod2017ieee">{{cite journal |last1=MacLeod |first1=Laura |last2=Greiler |first2=Michaela |last3=Storey |first3=Margaret-Anne|last4=Bird |first4=Christian|last5=Czerwonka |first5=Jacek|title=Code Reviewing in the Trenches: Challenges and Best Practices |journal= IEEE Software |volume=35 |issue=4 |pages=34 |date=2017 |doi=10.1109/MS.2017.265100500 |s2cid=49651487 | url=https://www.michaelagreiler.com/wp-content/uploads/2019/03/Code-Reviewing-in-the-Trenches-Understanding-Challenges-Best-Practices-and-Tool-Needs.pdf | access-date=2020-11-28 }}</ref>
Google,<ref name="sadowskiicse18">{{cite book |last1=Sadowski|first1=Caitlin |last2=Söderberg|first2=Emma|last3=Church|first3=Luke|last4=Sipko|first4=Michal|last5=Baachelli|first5=Alberto|title=Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice |chapter=Modern code review: A case study at google |pages=181–190 |date=2018 |doi=10.1145/3183519.3183525|isbn=9781450356596 |s2cid=49217999 |doi-access=free}}</ref>
and Facebook.

== 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>

== See also ==

* [[Committer]]
* [[Software review]]
* [[Software quality]]
* [[Best coding practices]]
* [[List of software development philosophies]]

== External links ==

* [https://blogs.oracle.com/javamagazine/five-code-review-antipatterns Five Code Review Antipatterns]
* [https://blogs.oracle.com/javamagazine/the-best-of-2020-the-10-most-popular-java-magazine-articles Java Magazine, Best of 2020]

== References ==
{{Reflist}}

[[Category:Source code]]
[[Category:Software review]]
[[Category:Peer review]]