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)