Sujet : Re: "RESET"
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : sci.electronics.designDate : 10. Jun 2025, 07:47:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <1028kei$1323e$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 06/06/2025 21:40, Carlos E.R. wrote:
On 2025-06-06 14:57, David Brown wrote:
On 06/06/2025 13:45, albert@spenarnc.xs4all.nl wrote:
In article <101p8sd$phe5$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
<SNIP>
I recall something of the opposite - a long time ago, we had to add a
variety of "safety" features to a product to fulfil a customer's safety
/ reliability checklist, without regard to how realistic the failure
scenarios were and without spending time and money on analysis. The
result was, IMHO, lower reliability because it was more likely for the
extra monitoring and checking hardware and software to fail than for the
original functional stuff to fail. Many of these extra checks were in
themselves impossible to test.
>
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.
>
>
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.
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.
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.
...