Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: sci.electronics.design
Subject: Re: "RESET"
Date: Tue, 10 Jun 2025 08:47:46 +0200
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <1028kei$1323e$1@dont-email.me>
References: <100thgs$v8cm$1@dont-email.me> <101ckan$i2b3$3@dont-email.me>
 <elqj3k17artqe5b9inne48ork5gurdp1u7@4ax.com> <101p8sd$phe5$1@dont-email.me>
 <nnd$646cdb8e$40d7b490@e501a0a625f47e62> <101uojq$298sh$1@dont-email.me>
 <brsbhlxu4f.ln2@Telcontar.valinor>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 10 Jun 2025 08:47:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c45cd0727a73b86eb70e02f35e9da787";
	logging-data="1149038"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+llfyp9FjwqmEp6XpXPxv0txvxTOKj/5s="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:xYuqYQh5gWK+nIshmUysuiCWIMA=
Content-Language: en-GB
In-Reply-To: <brsbhlxu4f.ln2@Telcontar.valinor>

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.
> 
> ...
>