In my experience, code reviews are a compromise between the extremes of no code reviews at all, and pair programming (which would be continuous code reviews).
The positive aspect of code reviews is that it gives another pair of eyes to find problems, and the early a problem is found the cheaper and easier it is to fix.
The negative aspect of code reviews is that -- unless the reviewers are intimately familiar with the code -- they tend to be a gloss level code review and find immaterial problems like "where the curly braces go" or "tabs used when spaces should be used" (or vice versa, in that perennial bike-shedding flame topic).
I tend to put code reviews in the same category as writing unit tests after-the-fact, or closing the barn door after the horse has bolted.
I think that pair programming (and hence continuous code review) works far better. Alas, I've only had the experience of pair programming a few times, as it has been in strong disfavor by management.
Similarly my experience with unit tests is that there is huge value to doing unit tests in the test-driven development style of writing the unit tests first; but they lose almost all their value if written in arrears. That value being to influence the formation of the code (the implementation level design).
Oh, there was one environment I was in where every team member was expected to do code reviews at their leisure for all check-ins, after the check-in had already gone into the source control repository. Completely informal, rather than formal code reviews. That worked pretty well, with higher quality reviews, and had less scheduling bother than trying to coordinate code reviews before check-in. It works because, as it turns out, code is extremely malleable and can be easily changed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my experience, code reviews are a compromise between the extremes of no code reviews at all, and pair programming (which would be continuous code reviews).
The positive aspect of code reviews is that it gives another pair of eyes to find problems, and the early a problem is found the cheaper and easier it is to fix.
The negative aspect of code reviews is that -- unless the reviewers are intimately familiar with the code -- they tend to be a gloss level code review and find immaterial problems like "where the curly braces go" or "tabs used when spaces should be used" (or vice versa, in that perennial bike-shedding flame topic).
I tend to put code reviews in the same category as writing unit tests after-the-fact, or closing the barn door after the horse has bolted.
I think that pair programming (and hence continuous code review) works far better. Alas, I've only had the experience of pair programming a few times, as it has been in strong disfavor by management.
Similarly my experience with unit tests is that there is huge value to doing unit tests in the test-driven development style of writing the unit tests first; but they lose almost all their value if written in arrears. That value being to influence the formation of the code (the implementation level design).
Oh, there was one environment I was in where every team member was expected to do code reviews at their leisure for all check-ins, after the check-in had already gone into the source control repository. Completely informal, rather than formal code reviews. That worked pretty well, with higher quality reviews, and had less scheduling bother than trying to coordinate code reviews before check-in. It works because, as it turns out, code is extremely malleable and can be easily changed.