4 ms·
> 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
by whilenot-dev 3mo ago
> 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 3mo agoYeah, 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 3mo agoI 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 3mo agoArguably, 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 3mo agoYeah, 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 3mo agoI've been asked to find bugs in PRs during interviews, even!