An interesting set of principles for code reviews.

Git pre-commit hooks indeed bring nice benefits. Like everything else they're not a panacea though.

Looks like I'm not alone advocating for commits which tell a story. Makes reviews so much nicer.

Indeed, carefully reading larger chunks of code and looking for the historical context around it can go a long way in finding bugs.

Both approaches have their pros and cons of course. Whatever you pick, it has to start with a care for quality shared within the team.

A good in-depth article about pair programming. Shows well the pros and cons.

A good reminder that reviewers have many things to keep in mind and evaluate. This is why what can be automated should be automated.

A bit of a self-serving post towards the end. Still I like it because it clearly mention that it's not about dropping all documentation in favor of the code (quite the contrary in fact, documentation is very much needed). It really is about treating code like documentation, putting the same care into it in terms of readability and understandability. If you wonder what code reviews are for... it's also for this readability concern.

Could be interesting if it gets standardized. Maybe other forges than Gerrit will start leveraging the concept, this would improve the review experience greatly on those.

Might be going a bit far if you use everything listed here. That said, it gives lots of good ideas so you might want to decide on what you should adopt on your project.

This is indeed a nice template for submitting changes for review. It's very thorough and helps reviewers.

Still very early days on this topic, clearly more studies are required. Still this one is interesting and indicates are clear link between code review anxiety and code review avoidance. If you're often procrastinating or rubber stamping code reviews, a workshop to reduce biases and showing you can manage your anxiety could improve things greatly.

Starts like a satire, but there's a serious conclusion in the end. Indeed, mind the power dynamics in code reviews. Be nice, steer away from those antipatterns, especially since you might be on the receiving end the next time.

I like the idea of getting all the review comments back into Git once things are merged. This works offline, makes you less dependent on the forge for historical data etc. Now we'd probably need to have the notes feature easier to use somehow.

Interesting approach to building a new code review system. I somehow doubt it'll get traction unfortunately but it has nice ideas baked in.

Good reasons to really make sure your organization practice code reviews.

I guess we kind of suspected it, this studies tends to prove it. Defects are more easily found in the first files of a code review rather than in the last ones.

Indeed, naming, comments and communication styles are three aspects often overlooked during reviews. They are very important though and shouldn't be neglected.

Excellent post about code reviews. I particularly like the introduction about the motivations, it's often forgotten.

We see this kind of comments in some reviews, this would benefit from being more widespread.