Talk:Code review

message: This article needs to be combined with software inspection. --Stevietheman
:Nevermind.  There appears to be some differentiation. --Stevietheman 18:01, 28 Dec 2004 (UTC)
replies: text:  Hello, there is a difference, see IEEE 1028-2008 or 1028-2008 - IEEE Standard for Software Reviews and Audits--𝔏92934923525 (talk) 23:38, 21 February 2021 (UTC)
thread_title:  Merge with [[software inspection]] 

message: What was planned for the (currently nonexistent) entry initial development phase which is linked here? TalkAboutQuality 21:39, 26 September 2006 (UTC)
thread_title:  [[Initial development phase]] 

message: This page is very pro code review. Whilst code review by the community is a key element of open source production, line-by-line code review is not considered an efficient method of defect removal in closed source projects. A likely reason for the disparity is that paid programmers would find this kind of process laborious and boring, whereas an interested third party looking at an open source project is likely to be more focused. DanielVale 02:54, 7 November 2006 (UTC)
replies: text: I would say instead that it's biased against code review.  The "criticism" section is longer than the "examples" section.  Furthermore, even if code review is not the most efficient method of finding defects, my personal experience is that it is good at finding code which is not well-written, and improving the structure makes future maintenance easier and less risky.  This web page lists several articles supporting the efficacy of code reviews.  Once I pass my next deadline, I will take a look at the articles on both sides and see what I can do to expand and improve this article.  (I will note here my personal experience that code review is an effective way of finding bugs that are unlikely to be discovered through validation (particularly in extremely complex systems, where it is not practical to test all paths through the code.) Matchups 15:13, 15 February 2007 (UTC)

text: The statement "line-by-line code review is not considered an efficient method of defect removal in closed source projects' begs a reference. Anecdotal accounts of inefficiency frequently find root cause in poor execution and/or measurement - though measures rarely exist in these cases. All the objective literature I've read make the exact opposite point: some examples are reported in detail at the SEI's site (e.g., Raytheon Electronic Systems Experience in Software Process Improvement), and others available through subscription-only at IEEE Explore. One could reasonably argue that claims of inefficiency are usually opinion and rarely, if ever, accompanied by any objective measures of the inefficiency.RobR 03:33, 27 July 2010 (UTC)
thread_title:  Code review bias 

message: This diff removed "idealistic wording" which previously stated that code review had improved certain projects and replaced it with a statement that it is claimed that code review improved the projects.  The revised text claims that it is impossible to tell with certainty that code review improved the projects, as they were only implemented once and thus there is no means of comparison.
I disagree.  Having performed many code reviews, I know that the changes I have proposed have improved the code, and I am confident that if any uninvolved person had looked at the before and after versions, they would agree.  There's no need for an external control; these two versions of the project are adequate to demonstrate the value of code review.
However, I do agree with Derek that there was a problem with the article, as the articles on the two purported example projects do not mention "code review," much less provide any justification for the claim that code review has improved them.  I believe that what should be done is to find RS's with specific documented examples of projects which have been improved by code review and use those in this article.  We should also remove Blender and Linux as examples, unless somebody with knowledge of those projects is able to edit their main articles to add a discussion of code review. Matchups 16:43, 8 July 2007 (UTC)
thread_title:  "Idealistic wording" 

message: The article seems to be focused on code review as a means of finding "defects". As a 25-years-experienced developer, I would say that is only a secondary purpose of code review. Code review is largely about honing a uniform coding culture within an enterprise, about making code more readable, etc. That is to say, it is not at all a substitute for testing: it is much more tied to the art of programming than the science of programming. - Jmabel | Talk 19:35, 25 February 2008 (UTC)
thread_title:  Dubious emphasis 

message: I think this article needs to be combined with Code audit 20:32, 22 Aug 2008 (UTC)
replies: text: I'm not opposed to this, but I'd like to point out that there is a pretty significant distinction between the two terms (at least how I understand it): code review usually takes place incrementally, reviewing all individual changes that are made to the code base. Code audit on the other hand usually takes place on a consistent snapshot of the code page to systematically check everything. -- intgr [talk] 14:49, 23 August 2008 (UTC)
thread_title:  Merge with Code audit 

message: The description of Lightweight code review (section Types) is vague and wildly generalized, and includes some errors.
First, there's no definition. The discussion seems to lump all of the review that aren't formal (I.e., Fagan Inspection, CMMI Peer Review, &c) under the umbrella term "Lightweight". Some example methods are suggested but not explained or referenced. This adds no value to the discussion.
It's unclear which of these is referred to in the statement that these "can be equally effective when done properly", with no suggestion as to what constitutes proper. 
The reference to Walkthrough is also in error: "Some of these may also be labeled a "Walkthrough" (informal)" - see Walkthrough.
Finally, the whole section is slanted in favor of "lightweight" versus "formal", e.g., the second and last paragraph. The latter cites a book by Jason Cohen, but Amazon.com shows only 4 mediocre reviews of the book. When I look at the author's four other works, I see nothing related to software at all - I'm hard pressed to lend any trust to his credentials!
At best, I would suggest subsections, or internal references, that covers each type - Inspections, Walkthroughs and Pair Programming are already defined, leaving "Over-the-shoulder", "Email pass-around", and "Tool-assisted code review"
I think claims about the relative effectiveness of methods that don't produce metrics should be omitted - or at least well caveated. RobR (talk) 04:28, 27 July 2010 (UTC)
thread_title:  Types discussion of "Lightweight" is too general/biased 

message: This link at the bottom: Security Code Review FAQs - Is actually a link to an IBM product page and is not a Security code review FAQ  —Preceding unsigned comment added by 80.93.22.26 (talk) 16:14, 12 November 2010 (UTC)
thread_title:  Commercial link to IBM  

message: Hello fellow Wikipedians,
I have just modified one external link on Code review. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20150428192217/http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf to http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 06:27, 12 December 2017 (UTC)
thread_title:  External links modified 

message: A couple of possible refs to improve this article. IEEE ACM CodeCurmudgeon (talk) 18:16, 29 January 2018 (UTC)
thread_title:  Additional sources 

message: I performed a larger restructuring of the article and removed the corresponding issue box. I also added a more thorough description of current change-based code review practices and of goals besides the finding of issues. I kept most of the old content (hope I didn't delete something by accident), albeit I consider some of it a bit too specialized. I added references to scientific articles for the new content and some of the old content where it was considered missing. TBaumSE (talk) 22:39, 23 September 2018 (UTC)
thread_title:  Larger restructuring