Re: "RESET"

Fair enough. Even with open source tools where there is usually little or no up-front capital cost, there can still be significant costs in time and effort.

Of course that does not mean that complexity should be ignored - it just means that you deal with it in other ways, such as getting in the habit of not writing overly complex code in the first place!

Indeed they are - and you have significantly different methods for developing, debugging and testing the code.

Automatic translation between programming languages is unlikely to be successful unless the languages have very similar structures (say, Pascal to C) or you are using the output just as an intermediary language for compilation rather than as a new version of the program (like using cfront for C++ to C transcompilation). Good code written in one language is going to be structured differently from good code written in a different programming language. And these old code bases might have started as a "good code" at one time - they are very unlikely to have remained so over decades of fiddling, fixing and expanding.

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.

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

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.

Long ago I worked with an early version of LabWindows for MsDOS (around

Yes. BTDT. The problem there is accidental complexity.

In my world, requirements that I wrote years before will pop up in inappropriate places, but nobody understands them or how they got there, so the people implementing those requirements are rightly afraid to touch anything. So one of my unspoken tasks is to delete stray requirements. The savings can be quite substantial.

Then there programmers in above their head.

Yep. One thing I learned the hard way when still young was to always prototype in a convenient language unrelated to the language of the delivered project, precisely to prevent that abuse.

True, but it's still an investment decision - does this approach result in worthwhile savings? Or should the effort be spent elsewhere?

This is very much a significant problem. My approach, unloved by process and language bigots alike, is to manually write the wiretap points in assembly code that rides the iron, invoking plain C (not C++) only if the wiretap decides to collect something. This is done because there are many more wiretaps in place than can be collected at once, so the decision to collect must be very quick.

Which wiretaps are active is determined by a big bitmap array at a static location in memory.

One form of wiretap checks for violation of a pre-specified assertion, collecting only on violation. This part is usually coded in plain C. Again, this must be quick, because assertions usually don't fail later during integration.

Analysis of the collected data is wholly offline.

This is after my time in the integration lab, but I'm curious.

What I used was a special assembly-coded ISR triggered by a CPU timer register. The time period was chosen to be mutually prime with all significant periods in the kernel, application, or library code. This ISR took a snapshot of the memory addresses that were executing when the ISR ran. This data was histogrammed, and the peaks chase back to locations in the software.

This was very useful on Ada83 projects, where lots of problems were because something that looks clean and simple actually mapped to a clumsy bit of Ada runtime system code - no amount of expert code review was going to figure this out. Once the problem was understood, we were able to paraphrase our way out of trouble, usually only by total avoidance of major parts of the language.

Joe

In article <101p8sd$phe5$ snipped-for-privacy@dont-email.me, David Brown snipped-for-privacy@hesbynett.no wrote: <SNIP>

I worked on the Dutch railway systems safety and control software. Once they added external control checking. I've seen the code. In places there was an 8 level indentation caused by if's switches and loops.

There was also a ban on automatic testing. I got on a row, because I used a 3 line batch file (.BAT) to save on repetitive typing.

Groetjes Albert

I've occasionally seen that kind of thing from developers who come from the PLC world, having trained as automation engineers. In that world, it's not uncommon to have long changes of conditionals, which used to be implemented as chains of relays. If there are a dozen safety checks, each with an "OK" output, then you have them all in a line. If this is later translated into C code, if might then be translated into a series of indented if statements. You get similarly bad code design from people who are not programmers or trained in programming (at least, not that type of programming), but have somehow ended up with the task.

That's a new one for me! I've certainly heard of management not wanting to spend time and money on doing much automatic testing, but never of people being actively against it like that.

The advantage of a state machine is that it forces people to know the state of the system.

I think it should be a chain of ANDs/ORs, not IFs.

...

There are many ways to structure such a code requirement. And I agree that a chain of "ands" will often be better than a chain of "ifs". (Sometimes you want a chain of "ors" - but never a chain mixing "and" and "or".) Usually, however, it is best if the chains can be broken up into smaller logical parts - local flag variables or small functions - to avoid long chains of anything.