Re: "RESET"

On 04/06/2025 19:54, Joe Gwinn wrote:

On Wed, 4 Jun 2025 17:53:19 +0200, David Brown
<david.brown@hesbynett.no> wrote:
 

On 04/06/2025 16:55, Joe Gwinn wrote:

Peer review of the code works better, because no pattern scanning tool
can tell spaghetti from inherent complexity.
>

>
That's certainly true in some cases.  It surprises me a little that your
experience was so much like that, but of course experiences differ.  My
experience (and I freely admit I haven't used complexity analysis tools
much) is that most functions can be relatively low complexity - the
inherently high complexity stuff is only a small proportion of the code.
  In one situation where this was not the case, I asked the programmer
to re-structure the whole thing - the code was badly designed from the
start and had become an incomprehensible mess.  Peer review did not
help, because the peer (me) couldn't figure out what was going on in the
code.

 All true, but at the end of the day, complexity metrics and coverage
tools didn't come even close to paying for itself, and so they
gradually faded.

Complexity metrics and dataflow analysis tools worked OK for me when working as a consultant digging companies out of deep holes they had got themselves into. They invariably looked hurt at the long list of defects that I would find almost immediately and I was almost always right about code with an insane value for McCabe's CCI being full of latent bugs.
Some code is irreversibly complex and necessarily so, but a lot of it is just the software equivalent of a rats nest prototype in electronics but treated as if it was production quality code. Management's ship it and be damned policy since they always wanted their sales target bonus.

However, it is entirely true that some code will be marked as very high
complexity by tools and yet easily and simply understood by human
reviewers.  If that is happening a lot in a code base, automatic tools
(at least the ones you are trying) are not going to be much use.

That goes with the territory but you only have to look at it once.

I would expect AI to be more useful in the context of static error
checkers, simulators, and fuzz testers rather than code coverage at
run-time.

 Forgotten from earlier: "Just to be clear - are you using
non-intrusive statistical code coverage tools (i.e., a background
thread, timer, etc., that samples the program counter of running code?
Or are you using a tool that does instrumentation when compiling?  I'm
trying to get an understanding of the kinds of "false hits" you are
seeing."
 The focus here is non-intrusive code evaluation tools.
 We also use intrusive tools and instrumentation in the integration
lab.

I find instrumentation often disturbs the problem that I am looking at. YMMV
I'm a fan of Intel's vTune for finding hotspots in serious code.
--
Martin Brown