[whilenot-dev]

> it is not in general possible to find bugs by examining the code.

Oh hell yes it is, at every level of abstraction even. We call those things code smell... A file descriptor that hasn't been closed, a coroutine that hasn't been awaited, a big try/catch block that just falls back to some value without logging the error, wrong type castings, etc.

As a general rule: Neither type checker, nor compiler, nor runtime should ever be steps that merely want to be satified - work with these steps and treat them as the valuable tools they are, and never work against them.

[saghm]

Yeah, I have no idea what they're talking about with that one. I've caught bugs when reviewing code without needing to run it before, and I've had the same happen to me in reverse, and I've seen it happen between others on reviews I was observing. I guess they could find some way to define "in general" so that this is technically true, but at that point it's not particularly meaningful.

[janalsncm]

I read it as a reference to some theoretical limitation like the Halting Problem.

Fine, in general it is not possible to tell if code will halt. But if I see a while(1) I’m going to check if the loop can break.

[layer8]

Arguably, if you can’t tell if the code will halt, the code is not acceptable. Code is acceptable if it can be properly reasoned about. If it can’t, it is not.

[saghm]

Yeah, this seems like a misunderstanding of the halting problem. You can prove that a program halts will halt; you just can't prove that it won't halt if it doesn't.

[nunez]

I've been asked to find bugs in PRs during interviews, even!