> I remember once I was giving a talk on code review and I said that code review doesn't prevent bugs and people were shaking their heads. Everyone hangs on to this one thing, but if you look at the majority of pull requests that have been approved you'll see a lack of comments about pontential bugs.
that's because the UX for github PRs sucks. Use Gerrit instead. It's not as pretty but it's super productive.
> I think the biggest problem with code reviews is it often becomes adversarial and people want to come out on top. I've had it more than once that someone has suggested another way of doing something, when I asked what the benefit of that way was or what was the downside of the way I was doing it no answer was forth coming however I was expected to implement their way. This becomes enraging when you point out flaws in their way but they can't find any benefit of their way.
that's not a problem caused by code review, it's caused by people who don't know how to work with others (or otherwise simply refuse to). to the degree that the code review process shines a light on this, that's good news, because that's a people problem that should be fixed.
> As well as, often people just don't want to do the extra work. You point about a bunch of small improvements. It's a pain.
when you look at a code review and you see problems in what's there, catching them in the code review is great, because that means less chance of having to fix it later.
if you see a code review and nothing's wrong with it, you just approve it. sometimes you can note things as "nits", meaning, fine for now but maybe next time do it this way.
> You end up with people asking for code style changes even tho there is a code style and the changes they're asking for aren't in those guidelines-
syntactical style and formatting should be automated, if not with tooling that actually rearranges the code in that way (e.g. [black](https://github.com/psf/black) for Python) then at least including well tuned linter rules. We use black, my own zimports tool for sorting imports, flake8 with four or five plugins as well as "black check", so we spend exactly zero time dealing with anything to do with style or code formatting, including having to even type any of it. if people are fighting over code style then there need to be tools that lock all of that down so there's no disagreements.
> People know it's a good thing to do but people have no idea how to code review and what is and what is not benefical during code review.
I work on the Openstack project and that is where I learned to do code review with Gerrit, it is completely essential for large projects and is an enormous productivity enhancement. Decades ago before CVS was even invented, the notion of using source control seemed crazy to me. That position was obviously insane, even though we were stuck using Visual Source Safe at the time. That's how it feels to me to be doing a real project today without code review and formatting tooling in place. Like even for myself, if working alone, for a large project with lots of changes I still use a code review tool, just to review myself.