4 ms·

I started digging into McCabe's Cyclomatic Complexity [1] after reading an interesting message on the DragonFlyBSD mailing list [2] regarding its questionable u

by jcr 11y ago

I started digging into McCabe's Cyclomatic Complexity [1] after reading an interesting message on the DragonFlyBSD mailing list [2] regarding its questionable usefulness on complex data structures and file system (HAMMER) code. The 'pmccabe' program [3] mentioned looks interesting, but I'm still figuring out what's available and I'm still working my way through the main wikipedia article (which links to the submitted article). I think the main problem is that complexity is a bug light for hackers; we know it will probably end badly, but the appeal is so intoxicating that we just can't help ourselves. [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity [2] http://lists.dragonflybsd.org/pipermail/users/2016-January/228535.html http://lists.dragonflybsd.org/pipermail/users/2016-January/2... [3] https://people.debian.org/~bame/pmccabe/overview.html https://people.debian.org/~bame/pmccabe/overview.html

nickpsecurity 11y ago
"I think the main problem is that complexity is a bug light for hackers; we know it will probably end badly, but the appeal is so intoxicating that we just can't help ourselves." That's a good metaphor. There's two ways of looking at this situation: human-centric and tool-centric. The human side is that anything too complex to understand can hide flaws in local implementation or interactions with other things. The tooling side is that things too complex for our tools to analyze can't give us the assurance level of alternatives. I think McCabe's works value is on tooling part but too often is assessed on human side. The counter-example is a good one where something is easy to verify for humans but produces a meaningless number that represents what tools would perceive. My rule of thumb is: Can you understand everything the software might do in success or error states? Have you tested that to be sure it does? Have you expressed it simply enough to apply static or dynamic analysis tools to show its safety against common cases of error? These things seem to be a pre-requisite for software that's correct by construction. Just one part of the process among many. Yet, a critical one. Work like McCabe's may help on tooling side. Yet, we often have a better shortcut: your code doesn't pass if the analysis can't prove its safe after X amount of runtime. "Animats" said that's Microsoft's approach to certification of drivers with their amazing SLAM verification kit: run it w/ an hour max. Driver quality is higher than ever despite complexity being higher than ever. Direct result of their assurance activities.

by jcr 11y ago

nickpsecurity 11y ago

"I think the main problem is that complexity is a bug light for hackers; we know it will probably end badly, but the appeal is so intoxicating that we just can't help ourselves." That's a good metaphor. There's two ways of looking at this situation: human-centric and tool-centric. The human side is that anything too complex to understand can hide flaws in local implementation or interactions with other things. The tooling side is that things too complex for our tools to analyze can't give us the assurance level of alternatives. I think McCabe's works value is on tooling part but too often is assessed on human side. The counter-example is a good one where something is easy to verify for humans but produces a meaningless number that represents what tools would perceive. My rule of thumb is: Can you understand everything the software might do in success or error states? Have you tested that to be sure it does? Have you expressed it simply enough to apply static or dynamic analysis tools to show its safety against common cases of error? These things seem to be a pre-requisite for software that's correct by construction. Just one part of the process among many. Yet, a critical one. Work like McCabe's may help on tooling side. Yet, we often have a better shortcut: your code doesn't pass if the analysis can't prove its safe after X amount of runtime. "Animats" said that's Microsoft's approach to certification of drivers with their amazing SLAM verification kit: run it w/ an hour max. Driver quality is higher than ever despite complexity being higher than ever. Direct result of their assurance activities.