Code reviews don't usually find bugs

Wikipedia (https://en.wikipedia.org/wiki/Code_review) says: "Empirical studies provide evidence that up to 75% of code review defects affect software evolvability/maintainability rather than functionality, suggesting that code reviews are an excellent tool for software companies with long product or system life cycles. This also means that less than 15% of the issues discussed in code reviews are related to bugs.

So, "don't usually" equals 15%. :^)

Deep dive: https://www.michaelagreiler.com/wp-content/uploads/2019/02/C...

> When reviewers look for these logic issues, they often run through the code line-by-line using different inputs and see if any lines cause the code to produce the wrong output.

I don't know of anyone that regularly does this during code reviews.

In my experience, automated tests help to catch regressions, i.e., they help catch error cases that people have already anticipated. If the system fails in some brand new unexpected way, you won't have tests for it by definition.

Similarly, static analysis can help catch certain classes of bugs, but there's plenty of things they won't be able to spot.

Yes, they're both useful, but neither of these is a replacement for code review. They're all complementary.

I just did a code review today where I didn’t find any bug but I forced the “developer” to rewrite the whole thing. He didn’t write a single line of code with a minimum of maintainability in mind…

Tests find bugs, code reviews look for quality. Sometimes I can spot a bug but it’s not my primary goal.

That's quite the evisceration of a strawman that you've got there. He certainly won't be walking to Oz with Dorothy anytime soon.

My counterpoint:

- Most code reviews of my code don't find bugs.

- At least half of the bugs I write are caught during code review.

Both are true.

> Automated unit and integration tests are far better at finding logical bugs in code than human reviewers.

My friend, who do you think writes the tests, and how do you think they get into the system?

Often we're writing new functionality. There are no tests for it, so they're part of the pull request, and must be reviewed to make sure they're actually testing the right thing!

80% of the value of code review comes in the preparation for review, not the review itself.

I'd like to see the difference in bug detection between "pull requests" vs. "over-the-shoulder code reviews".

Edit: or, rather, in my experience the author of the code often finds the bugs when explaining it to the person standing next to them. This goes away in the GitHub-style pull request.

I've always thought the purpose of code review was to determine if the implementation was consistent from an architectural perspective, bug finding seems like something that should be caught by unit tests and other tools (unless you happen to catch it by chance).

This looks like some kind of spam, I'm even tempted to say AI generated.

I didn't think you need to find that many bugs to make code reviews useful. Even if you only find a handful of bugs it is probably with it. Keep in mind the longer the code exists the more expensive it is to fix it. Finding a bug early can save a lot of time and money down they line. Also as someone else pointed out they can help with code quality. So they can help prevent someone adding a bug later.

1. the submitted title does not match the article, and the article does not support the claim of the title. (Its thesis is closer to "code reviews are tedious and a bottleneck".)

2. This is an ad.

It seems like I incorrectly presumed this was well known. I will review your code, but it's your responsibility to figure out bugs. Sometimes I spot them though!

Code reviews also help spreading good practices and knowledge

I found plenty of bugs by just reading code...

And yes i foster code review in my team and yes its a skill people need to learn.