From: clubley@remove_me.eisner.decus.org-Earth.UFP

On 2025-08-19, Dan Cross  wrote:
> In article <1081rg2$3njqo$3@dont-email.me>,
> Simon Clubley   wrote:
>>
>>I write simple to understand code, not clever code, even when the
>>problem it is solving is complex or has a lot of functionality
>>built into the problem.
>>
>>I've found it makes code more robust and easier for others to read,
>>especially when they may not have the knowledge you have when you
>>wrote the original code.
>
> I'm curious how this expresses itself with respect to e.g. the
> short-circuiting thing, though.  For instance, this might be
> common in C:
>
>     struct something *p;
>     ...
>     if (p != NULL && p->ptr != NULL && something(*p->ptr)) {
> 	// Do something here.
>     }
>
> This, of course, relies on short-circuiting to avoid
> dereferncing either `p` or `*p->ptr` if either is NULL.  What
> is the alternative?
>
>     if (p != NULL) {
>         if (p->ptr != NULL) {
> 	    if (something(*p->ptr)) {
> 		// Do something....
> 	    }
>         }
>     }
>
> If I dare say so, this is strictly worse because the code is now
> much more heavily indented.

Indented properly (not as in your next example!) I find that very
readable and is mostly how I would write it although I do use code
like your return example when appropriate. This is my variant:

	if (p != NULL)
		{
		if (p->ptr != NULL)
			{
			if (something(*p->ptr))
				{
				// Do something....
				}
			}
		}

In case that doesn't survive a NNTP client, it is in Whitesmiths format:

https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths

I like to spread out code vertically as I find it is easier to read.
We are no longer in the era of VT50/52/100 terminals. :-)

>
> Ken Thompson used to avoid things like this by writing such code
> as:
>
>     if (p != NULL)
>     if (p->ptr != NULL)
>     if (something(p->ptr)) {
>         // Do something....
>     }
>

YUCK * 1000!!! That's horrible!!! :-)

> Which has a certain elegance to it, but automated code
> formatters inevitably don't understand it (and at this point,
> one really ought to be using an automated formatter whenever
> possible).
>
> AN alternative might be to extract the conditional and put it
> into an auxiliary function, and use something similar to
> Dijkstra's guarded commands:
>
>     void
>     maybe_do_something(struct something *p)
>     {
>         if (p == NULL)
> 	    return;
> 	if (p->ptr == NULL)
> 	    return;
> 	if (!something(*p->ptr))
> 	    return;
> 	// Now do something.
>     }
>
> I would argue that this is better than the previous example, and
> possibly on par with or better than the original: if nothing
> else, it gives a name to the operation.  This is of course just
> a contrived example, so the name here is meaningless, but one
> hopes that in a real program a name with some semantic meaning
> would be chosen.
>

There is one difference for me here however. _All_ single conditional
statements as in the above example are placed in braces to help avoid
the possibility of a later editing error.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)