From: cross@spitfire.i.gajendra.net
In article <1084eul$afbj$2@dont-email.me>,
Simon Clubley wrote:
>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
Well...at least it's not GNU style. :-D
Jokes aside, I've found this easy to turn into a mess, if the
nested 'if's also have 'else's. In the context where we're
talking about a replacement for short-circuiting booleans,
that's not generally a consideration, though.
>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. :-)
Eh, vertical density has some cognitive advantages. Like it all
things, it can be taken to an extreme, however. Sometimes it's
useful to burn vertical space for readability; sometimes that is
done excessively, defeating the purpose.
>> 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!!! :-)
Heh. Well, tell it to Ken; in a lot of ways, he's responible
for much of the language (via Dennis Ritchie), so he can do what
more or less what he wants. :-)
>> 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.
Oh, that's fine; I have no objection to that. On USENET, I'd
omit that just for brevity, however. Here, I _do_ care about
vertical space!
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
