Comment by grayhatter | Hacker News Reader

Comment by grayhatter | Hacker News Reader

> many people misunderstand the purpose of code review

Oooh, I bet including the author? Yeah, right there, he fails to make any qualifications for his statement, making it factually incorrect.

There are plenty of reasons to do code review. If you force me to, I'll define it as information transfer. The point is to have a conversation about the code. To expand both people's understanding about the codebase. Everything on top of that is extra. I've found real and significant bugs doing code review. In large part because I understand the codebase better than the author. That's finding and preventing bugs.

I also read PRs looking for malicious code trying to sneak in, you never know, the person I've called my best friend, someone with opsec better than mine, may suddenly have turned evil and this is the PR where they're finally sneaking in the back door.... that's never happened yet, but fingers crossed!

> As everyone should know by now, it is not in general possible to find bugs by examining the code.

... I'd love to know what the author really meant to write here, because it certainly wasn't this.

> I've found real and significant bugs doing code review. In large part because I understand the codebase better than the author. That's finding and preventing bugs.

this. was a lead in small businesses working with very inexperienced people in one team -- literally having to teach them git -- and another with outsourced devs who had one day a week for us and could barely remember cos they context switched onto other projects for the other 4 days a week etc.

my job was to always know the most about the systems, what we're trying to achieve with the systems and what is in the codebases. answer questions. send links to people. know which devs to ask for more detail etc. i never necessarily knew everything about frameworks, libraries, package updates, new tools etc., but i knew our system/devs/goals/products inside and out.

as i said to several people, your first PR submission is just your first public draft. i will find bugs. i will find things that need changing. it's not personal. it's just about making your PR better than it was. this is an opportunity to learn from me.

the author of the article seems to be considering code review from an idealised situation -- this never occurs in reality, most of us have to make do.

and that means changing focus of code review for what is needed, rather than what is ideal.

He's a mathematician, so what he means by "in general", is "in every possible case", or "without exception", so what I think he means is, "not all bugs will be found by code review." I agree it probably could have been made more clear.

But a) that's not what his words mean in English and b) that's irrelevant.

"in general" quantifies over all occasions, not over all bugs on one occasion.

To quote my own response:

===

Apparently the mathematician author doesn't understand the meaning of his own natural language quantifiers. “it is not in general possible to find bugs by examining the code” means “it is not in general possible to find ANY bugs by examining the code”, not “it is not in general possible to find ALL bugs by examining the code”.

And the first interpretation is relevant but wrong, whereas the second interpretation is true but irrelevant.

P.S. It seems that the author meant to say “it is not in general possible to find a given bug by examining the code”, i.e., "not (for all bugs B it is possible to find B)", which again is true but not relevant.

===

Reply on news.ycombinator.com