Re: ANSI-fy of ranlib, ruptime and rdist [patches]
:Also, while not checking a return value is usually not the cause of a
:bug, it can often provide very useful clues for the onset of a bug.
:I've had people complain, for example, that an IPC library I wrote isn't
:working properly, or that it's causing a coredump. Upon closer
:inspection, they were ignoring the fact that an xxxConnect() call was
:returning ECONNREFUSED.
:
:Maybe we just have sloppier programmers at work? <shrug>
Yes, but the problem is that 99.9% of the time the cases where one
isn't checking the return value are, in fact, not bugs. By imposing
a rule which requires code handling of a return value every single
time, you create a situation where 99.9% of the code that otherwise
could simply ignore the return value must now explicitly handle it in
some way. With enough of these rules the code basically turns into an
unreadable mess, where most of the code is handling language requirements
rather then implementing the algorithm, and the meat is so obscured that
even a good programmer (other then the one who wrote it) would not be
able to follow or understand what the code is actually trying to do.
There is only one way to write a good program, and that is to be a good
programmer. It is absurdly easy to write Java or C++ or Eiffel that
adheres to all the requirements but is still full of bugs and utterly
incomprehensible to everyone else. In some respects, the class hierarchy
actually makes it worse, though I personally like the idea of classes (as
long as they aren't abstracted out to obscene levels). The idea of
language-enforced bug detection through complete formalization of all
variable and procedural interactions doesn't work in practice.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 19 之 20 篇)：