🚀 go-pugleaf

On 8 Mar 1996 17:03:47 -0600, Jerry Coffin <jcoffin@rmii.com> wrote:
>In article <4hlalm$4i6@solutions.solon.com>, rog@ohm.york.ac.uk says...
>>   for (i = 0; i < NUMSECTS; i++)
>>     if ((categ[i].whichexe & prognum) && (*categ[i].isfn)(info, t))
>>       break;
>> 
>> is this a bad way to write code ?
>
>It's pretty hard to give a solid judgement of something being "bad" or not, and 
>without more information about the surrounding code, it changes from pretty hard to 
>simply impossible, IMO.
>
>My question in looking at a loop like those above would be whether you intend to 
>finish the loop or not.  For instance, if your last loop is intended to process the 
>entire `categ' array, but might quit if the system is judged `insane' or somesuch, 
>then a break is likely reasonable.  OTOH, if the loop is really searching through 
>the `categ' array, and the only time `i' equals `NUMSECTS' is if the user has asked 
>to, say, delete something that can't be found because it doesn't exist, then I'd 
>like it a lot less.

i guess you wouldn't like it much then.

i like code like the above because:

  a) at first glance the range of the search is obvious
     (i ranges from 0 to NUMSECTS-1)

  b) the condition is perhaps not easy, but it is logically
     separate from the looping condition, and easier to comprehend
     in isolation (given the known range of i)

  c) termination condition is trivially obvious:
       either i == NUMSECTS or i is the first i for which the
       condition held true.

  d) when scanning the code, the exact condition for breaking
     out of the loop does not have to be examined in detail.
     what should stand out is the most important postcondition of
     the loop: that i >= 0 and i <= NUMSECTS and if i == NUMSECTS
     then the condition was false for all i in the range of the loop.
     

>In short, IMO, it's largely a matter of the loop condition accurately reflecting 
>the basic idea of when the loop will normally exit.  Even if it complicates reading 
>that line of code, if it makes the overall intent of that section of code more 
>obvious, it's likely worthwhile.

i don't attach much importance to making the loop condition actually
reflect the normal termination condition of the loop.  if there's
a break statement anywhere inside the loop, it is as important to
the reader of the code regardless of whether it is the normal state
of affairs or not.

what is important IMHO is that the most important properties of
the code being examined are evident to the reader.  this is why
idioms have a revered place at the heart of C - they make it possible
to tell at a glance the intended function of certain segments of
code.

this is also why code which almost matches an idiom (but not quite)
is disliked - it means the reader of the code actually has to think
about it, and quite possibly get it wrong.

maybe i am completely up the wrong track.
opposing views ?

  cheers,
    rog.