The primary purpose of code review is to find code that will be hard to maintain

Posted by ColinWright 11 hours ago

The primary purpose of code review is to find code that will be hard to maintain(mathstodon.xyz)

297 points | 156 commentspage 4

ak217 4 hours ago|

The primary purpose of code review is whatever your organization decides it wants it to be. The post makes a good enough point but undermines it with this dogma.

zabil 7 hours ago||

There more things in a pull request other that just reviews. It can run a build pipeline and give feedback, provision test instances to run quick tests.

It can also be used to add context and have a conversation around the why's before merging. And yeah while it's not the main purpose we've caught a lot of bugs too just from the statically reviewing code.

spacington 9 hours ago||

Found plenty of bugs by reading/doing code review.

wayne-werwolf 8 hours ago|

As other's already pointed out, the author argues about the primary intent of code review. Of course you find bugs while doing it, and that's a nice side effect, but doing code reviews to assert correctness is maybe suboptimal QA. At least that is my take ...

jibal 3 hours ago||

The author made multiple statements, and one of them was “it is not in general possible to find bugs by examining the code”, which is simply false.

Ozzie_osman 9 hours ago||

100% this. This is why it's so hard to trust AI on code reviews, at least for now.

havblue 7 hours ago||

I've been at a lot of companies where code is held hostage by the reviewers, specifically leads or wannabe leads. Interfaces matter. Maintainability matters. Memory allocation certainly matters. Code reviews frequently go down the rabbit hole of how the reviewer would prefer to design it and a long back and forth until the developer has, "explained himself", like it's a Breaking Bad confrontation. I think it devolves into a status battle.

dijksterhuis 6 hours ago|

without knowing the people involved, or any further nuance/context -- i had a PhD supervisor like this. he was always looking for holes. always disliked the way i was proposing something. always looking to find the thing that's wrong. the way to deal with him was to have thorough answers to as many questions he might ask before he asks them. learning to predict his questions was the real training for my PhD.

it taught me to show my working, as if i were in math class. which meant fully writing things up before meeting with him.

> how the reviewer would prefer to design it

sounds like they're trying to find holes. dunno if you do this already, but if not, try to fill the holes beforehand with conclusive and extensive write up (show the working). maybe ask them before coding how they would design X and then dedicate a section of the write up to why X cannot or was not designed that way.

answer their questions before they have a chance to ask the questions.

resters 8 hours ago||

I make code review and PR approval optional for my teams. A solid process should emerge from respect and peer pressure alone.

jy14898 8 hours ago||

Not all bugs are buffer overflows, many are just the code not doing what it claimed at a high level

ChrisMarshallNY 7 hours ago|

It's also important to help other members of the team to learn and understand.

More comments...