steveweick wrote:
Do you need to read the code to verify reliability as your next few
sentences seems to imply? For that to be true, the reader would have to be
able to spot bugs through inspection.  While that is certainly one way to
spot bugs, I seriously doubt that any shop would rely on code inspection,
when millions of dollars of potential recall costs are on the line.
I think many would agree that code inspections do find (serious) bugs, that may not show up from testing. I'm sure your company conducts code inspection meetings as a part of all code development. We (the company I work for) certainly do. I know I've seen change logs that read something like "Fixed possible buffer overflow in foo..." for open source projects here and there as well.

In fact the SQLite marketing does not rely on code inspection as its
argument for why the code is reliable. Check it out.
That would be bad if they did, I agree. But all the testing in the world won't uncover all the bugs either, in a complex piece of code. See . "The Ptolemy II system itself began to be widely used, and every use of the system exercised this code. No problems were observed until the code deadlocked on April 26, 2004, four years later." And that was after code inspections, regression tests and belt and braces programming techniques!
All of that said, I do admire the elegance of the SQLite code.  It makes
entertaining reading.  Unfortunately elegance does not translate into
performance or reliability.
Not necessarily, but it often does, and can make for better maintainability too. I've not trawled through to SQLite code myself, so couldn't comment. But it does have quite a few big name users, and an active and helpful user forum, which gives me good vibes at least.


To unsubscribe, send email to [EMAIL PROTECTED]

Reply via email to