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

Join the discussion

• Hacker News
• The primary purpose of code review is to maintain existing hierarchy by preventing junior SWEs from getting promoted by committing code that is smarter than what the senior architect can understand.
  by cat_plus_plus
• If the code is so smart that it's not easily understandable, it's not easily fixable. My transition from junior to senior was accompanied by the realization that simpler is nearly always better.
  by SketchySeaBeast
• No, the real reason for the code review is to protect the moat of senior engineers/leaders that would nitpick on minute details of code while ignoring the big picture to make sure they can gatekeep any promotions and their competition.
  by storus
• If that's how it functions where you work, I'd be looking for a new job.
  by seabrookmx
• Uh.. why not both?
  by high_na_euv
• Because the reviewer is not magical. If there was something in the code the author couldn't see, the reviewer probably won't see it either.

  The way to confirm that code does not have bugs is testing. So the reviewer is not looking at the code saying "this will work", they're looking at the code saying "I understand how this works, it makes sense."

  Evidence that the code is safe is something that also should be provided in the PR, but it is not the main code. It is ideally test automation that is just as understandable as the feature code, but failing that ad-hoc test evidence or a specific step-by-step plan with evidence of execution is good too.

  by Pxtl
• To have two primary purposes is difficult in English.
  by pessimizer
• > As everyone should know by now, it is not in general possible to find bugs by examining the code.

  Lost me here. I would agree that it’s not possible to find every bug by examining code, but in real code reviews bugs and errors are identified by reviewers all the time. Reviewers lend their past experience to the situation, identify some unnoticed interaction, think of an edge case that the author hadn’t considered, or some times just notice simple logic errors.

  Code review is a fresh set of eyes. When we write code eventually parts of it get accepted in our minds as done or correct and we can start missing things that are obvious to a reviewer.

  I’m not a fan of these blanket declarations that code review isn’t about reviewing code. I’ve read countless hot takes like this that code review is about some other thing (finding unmaintainable code, knowledge transfer, etc) that all miss the point that code review isn’t about one thing. These reductions and exclusions can be really misleading.

  by Aurornis
• > in real code reviews bugs and errors are identified by reviewers all the time.

  I think that this would be better directed at the person who posted "no one ever finds bugs during code review" rather than at the person who said that just re-reading code is (obviously) not an effective way of debugging, and is better thought of as a time to make code clear enough that bugs will be more apparent or less likely to be introduced by later authors.

  > I’m not a fan of these blanket declarations that code review isn’t about reviewing code.

  Using a shovel to dig a hole isn't about using a shovel, it's about digging a hole. Reviewing code is a necessary prerequisite to finding code that will be hard to maintain (and finding any number of other things, and knowledge transfer, and getting acquainted with coworkers' coding styles and domains, etc.) It is not a purpose in itself, but a tool.

  > code review isn’t about one thing.

  But you just said that code review is about reviewing code, and explicitly not about "some other thing" in the beginning of the sentence, right before listing two other things that code review could be about, and then insisting that it could be about many other things. The author is saying that it is primarily about one thing, likely because in their opinion it is most effective at that one thing, and that one thing goes a long way into solving other issues.

  It isn't like they said "ignore bugs during code review, never learn anything from it."

  I agree with the OP. Code reviews are finishing steps where things are polished, and polished code should be correct code, but more importantly intelligible code. If your code is clear, the mistakes will be obvious to more people than if your code is not readable. To make it simple: you've written something and it feels done, now you want someone to read it to see if it makes sense to them. No different than any other type of writing.

  by pessimizer
• This is the big thing I'm struggling with:

  Code reviews are still a critical step in most workflows. Though seems like everyone uses them for a different purpose: extra pair of eyes to meet a regulation/security, style police, and what this one says: maintainability.

  And at the same time, code reviews are now a massive bottleneck in the development pipeline. Frankly, in a lot of teams they have been that for a long time. Though many would argue it was the only thing stopping absolute crap going into production.

  But in a world where none of us writes code anymore, and I think we're there, even if the future is "just not evenly distributed" (Gibson), why should we have to do code reviews, the worst job of all?

  Leaves me thinking that code reviews will land in the dustbin of history.

  But for now I don't have a better solution.

  by lukasco
• One of my favorite little things to notice is when everybody thinks they know what something is, and they all agree about it, but they in fact don't agree. In this case we have the statement "Code review is a good idea". What right-minded software engineer could possibly disagree with that?

  But then notice 1. the number of people jumping up to say "No, you don't understand the point of code review" and 2. how what follows "The point is..." varies between so many different people. I can't quite say it's a unique take per person, as I've seen before, there are some common threads, but they are also not all the same answer by any means either.

  In this case, there isn't a "the" point of code review to discuss. It turns out that while we all may have thought we were doing it for the same reasons, we aren't. This is real. We don't have the same goals, we don't have the same methodology, and thus, the value we get from it may be different. And in fact it is perfectly reasonable to discuss the multiple cost/benefits ratios that differ across the various definitions, because the simplification "it's good, end of story" is destroying important distinctions.

  In this situation, it is helpful to frame this as a matter of the costs and benefits of the various options available. Forget the statement "code review is good"; it is fallacious to start with that statement as an axiom and then argue about whether or not your definition of "code review" is or is not the "correct" definition so that your definition gets the "good" attribute applied to it. Consider the options directly.

  (I have to admit I've used this effect in anger... in meetings where I can tell that everybody thinks they know what some project is but I can tell they all have a different definition of it in mind, but I also know it's not going to happen anyhow, I don't chase down the differences. Sometimes you can use this to your advantage to cut short what would otherwise be a quite interminable, yet ultimately pointless, meeting.)

  by jerf
• > What right-minded software engineer could possibly disagree with that?

  No matter what "code review" ultimately is intended to mean it will have tradeoffs making its use a bad idea at least sometimes. There is no engineer who could agree with that statement. Suffice to say that the software industry attracts a lot of non-engineers, however.

  by win311fwg
• > If I work until I'm exhausted and find three bugs, someone might still complain later that I missed a fourth and I should have tried harder.

  This is a weird take. Less bugs is less bugs, just because you maybe didn't find them all doesn't undermine the value of finding some.

  by moebrowne
• Look at the state of the comments on that thread.

  "This is completely false! Code is review is to ..." proceeds to state an opinion.

  Sometimes, some days, I just look forward to not having to deal with programmer hubris ever again.

  by munksbeer
• I remember a time when the sole point of code review was to answer the question 'is this change going to break any other work currently in-progress?' That was it.

  it was expected to be a short-duration fixed-scope activity with a clear Go-NoGo answer, and you would have gotten roasted for digressing into navel-gazing and distracted conversations about armchair philosophy. if the change worked as-advertised and didn't break your work, then it was a 'go', get back to work...

  by nacozarina
• In most projects I worked on it is plain burocracy to ensure the solution architect is happy with their hexagonal or clean architecture.

  Really I can count up to five the amount of projects where good code review actually took place.

  by pjmlp
• It's kinda funny that we all agree that code review is important but we cannot agree why exactly it is important. Imagine a bunch of ancient shamans arguing why exactly local volcano needs to be fed one virgin a year but all being in agreement that it does.
  by anal_reactor
• It's also important to help other members of the team to learn and understand.
  by ChrisMarshallNY
• "Anyone who depends on code review to find bugs is living in a fool's paradise. As everyone should know by now, it is not in general possible to find bugs by examining the code."

  I think this is pretty clumsily stated. The way I would best summarize what it should be is "The person best suited to address bugs in the code is the author/owner." That's usually some blend of detecting and fixing them. Code review can certainly surface bug-prone patterns being introduced (or extended), and even catch them directly.

  But as many of the peer commenters state here, the depth of code review that finds buggy behavior and risky structuring is pretty involved and an expensive use of time. At most places I've reviewed code prior, this was always amortized as cost of doing business. Maybe partly because there wasn't a "theoretically" faster alternative, and maybe because we were trying to avoid 2 steps forward 1 step back.

  Now, I think we are struggling with "the clinical trial problem" where there is more pressure to ship using AI but it doesn't actually abridge the QAing and review part. The problem with trying to abridge that part is it just creates backpressure like a spring and then catastrophically explodes 10x worse later on than if it was dealt with directly. It can be very easy to build a circle of pitfalls that were completely unnecessary. I think that automated code review techniques are going to have to evolve to keep up with the new paths that code can be generated through.

  And to anyone that has to go through new, arms race enhanced forms of slop cannons -- my heart goes out to you, because the old ones were never particularly pleasant to deal with.

  by yowlingcat
• Nowadays the main point of PR's is to find out what Claude has been coding for me.
  by misja111
• lol, but also, nearly every comment in this thread seems so old school, as if the game hasn't completely changed.

  PRs for knowledge transfer? I don't need it, I'll just ask an LLM a question if I have one.

  PRs for enforcing good design? I dunno, if it's a terrible design, we'll just change it since change is so much less work now.

  by peder
• I think you're missing the point of code review. By the time when the PR is ready to merge, discussions around the architecture and how the code should be structured should already be part of the tech design of a given feature. So the discussion around whether a A feature is built and planned in a maintainable way, should be way before a PR is filed. A PR review is making sure that you verify against the already agreed-upon structure, making sure everything matches the plan, and also find bugs and stuff that was missed, according to the plan.
  by othmanosx
• Not every codebase project etc use such workflow

  Also such approach doesnt work with bug fixes / regressions

  by high_na_euv
• Why are we still so obsessed about maintaining code when rewriting it is very low cost now?
  by mannanj
• Not all bugs are buffer overflows, many are just the code not doing what it claimed at a high level
  by jy14898
• This absurdly cramped view already has significant pushback/refutation in the responses on mathstodon.
  by jibal
• Unmaintainable is a bug. You just decided that you think code review is only meant to find one type of bug. Cool?
  by lazyasciiart
• I make code review and PR approval optional for my teams. A solid process should emerge from respect and peer pressure alone.
  by resters
• 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.
  by havblue
• 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.

  by dijksterhuis