| |||||||||||||
|
| |||||||||||||
Rate of bugs and rate of security holes are mostly uncorrelatedRate of bugs and rate of security holes are mostly uncorrelatedPosted Mar 7, 2006 19:10 UTC (Tue) by Junior_Samples (guest, #26737)In reply to: Rate of bugs and rate of security holes are mostly uncorrelated by nix Parent article: Coverity releases first defect survey results "In any case, the more complex the code, the less likely it is that a static checker like Coverity's will isolate real faults without special understanding of that project." Au contraire. Complexity in and of itself is a defect. The measurement of complexity is considered the one of best metrics of software quality there is. It has been shown time and again that defects grow exponentially as complexity is increased. The fact that an automated parser should struggle with code which is "more complex" and full of obscure idioms should be proof enough that the code is defective. Sadly, use of complexity analysis seems to be completely absent in the OSS domain despite the fact that basic measurement of complexity using McCabe's or Halstead's methods are very straightforward, and freely available automated parsers exist. The Linux Journal has an article about one such tool for Python.
(Log in to post comments)
Rate of bugs and rate of security holes are mostly uncorrelated Posted Mar 8, 2006 0:54 UTC (Wed) by nix (subscriber, #2304) [Link] Code which is complex is only defective if it's doing a simple job despite that complexity.
Things like GCC, say, are doing very complex jobs: now perhaps GCC is more complex than it needs to be if all were ideal, but there's no way you'll ever get it simple enough to make static analysis easy. It does a very complex job.
(And so do the knottier parts of the kernel.)
|
|
||||||||||||