> What kind of stylistic changes are you talking about?
It's the level above the decisions a tool can enforce which I've seen tending towards bikeshedding.
> But code reviews are for other things than just catching bugs...
I don't dispute that there is value here. I think that value is tremendously overplayed in comparison to the costs incurred. Or rather, I think the costs are underplayed.
> And why is it a bad use of time if it actually helps finding bugs?
Tweak the numbers slightly: would it be reasonable, for that purpose, at a rate of 1%? 0.1%? Think how much time has been spent on the reviews at that point, and how much delay has been injected between initial commit and release. There comes a point where you have to look at the process and think "this is not a worthwhile investment of everyone's time."
> What method do you know that is more efficient?
I don't. That's the point. As an industry we seem to have latched on to code reviews because they're one of the very few techniques which there's actually any evidence for, to the extent that questioning whether they're the best we can do is discouraged.
Code reviews should not devolve into bikeshedding. That is a problem of people not understanding the purpose and value of code reviews, not a problem with the concept of code reviews. Ignore the issue if it is not important or make a ruling and move on.
If your code reviews find bugs left and right I would say it indicates a deeper problem: Why are there so many easy-to-spot bugs in the first place? The amount of bugs found is definitely not a measurement of success. The purpose of review is to improve overall readability, competence, and code quality to level were fewer bugs are introduced in the first place.
It's the level above the decisions a tool can enforce which I've seen tending towards bikeshedding.
> But code reviews are for other things than just catching bugs...
I don't dispute that there is value here. I think that value is tremendously overplayed in comparison to the costs incurred. Or rather, I think the costs are underplayed.
> And why is it a bad use of time if it actually helps finding bugs?
Tweak the numbers slightly: would it be reasonable, for that purpose, at a rate of 1%? 0.1%? Think how much time has been spent on the reviews at that point, and how much delay has been injected between initial commit and release. There comes a point where you have to look at the process and think "this is not a worthwhile investment of everyone's time."
> What method do you know that is more efficient?
I don't. That's the point. As an industry we seem to have latched on to code reviews because they're one of the very few techniques which there's actually any evidence for, to the extent that questioning whether they're the best we can do is discouraged.