Re: C and MISRA, blues... (arithmetic shifts)



Steve at fivetrees wrote:
"Richard Phillips" <raphillips@xxxxxxxxxxxx> wrote in message
news:kukQj.59491$h65.48326@xxxxxxxxxxxxxxxxxxxxxxx
* You're not supposed to use "goto". Avoiding this when you're
learning to write code is good practise, but it's very useful in a
limited set of circumstances, if used properly. I remember a manager
of mine telling a work colleague once that using "goto" was bad
practise, I then showed my colleague my copy of K+R which basically
put him right.

* You're not supposed to exit from a controlled loop prematurely.

Avoiding "goto" means avoiding unstructured design (i.e. using only
only closed structures - one start, one end, any other context
signalled by other means than programme flow).

Sorry, I think that's just wrong. If K+R think it's ok and include it in
the language, I think there must be some point to it.
The one case I've encountered where it's "needed" is deeply nested
conditional code. Often encoutered in communications, where you need to
test lots of conditions before a packet of data is "accepted". If the data
is rejected at the final check, goto gets you right back out gracefully
without lots of extra checking code.


Exiting a control loop prematurely is not a case of a goto - it's
still a case of one start, one end. It just avoids a layer of
indenting and promotes readability.


I never said goto should be used in this instance.

Things like jump tables are not lists of gotos - they're a list of
(derefenced, if you insist) function pointers.

Summary: avoiding goto as a design concept is a Good Thing.

In most cases, yes. But see above.

Avoiding
gotos as a means of implementing good structure is simply
misunderstanding the point. I've seen (possibly on this ng) someone
defending goto on the basis that CPUs only know about branches and
jumps anyway. Follocks.

It's *not* about implementation. It's about design. If you use gotos
to implement an IF THEN ELSE ENDIF structure, I could care less. It's
still structured.

Bottom line: uncontrolled program flow is a Bad Thing. If you can't
look at a chunk of code and know the answer to the question "How did
I get here?" - warning!

Steve
(another 2c poorer)


.



Relevant Pages

  • Re: C and MISRA, blues... (arithmetic shifts)
    ... practise, I then showed my colleague my copy of K+R which basically ... Avoiding "goto" means avoiding unstructured design (i.e. using only only ... avoiding goto as a design concept is a Good Thing. ...
    (comp.arch.embedded)
  • Re: C and MISRA, blues... (arithmetic shifts)
    ... of mine telling a work colleague once that using "goto" was bad ... practise, I then showed my colleague my copy of K+R which basically ... In those cases you need to deviate and be able to stand up in court in 3 years time with your deviation. ... Intestinally the "goto" is bad" came from a paper by Dykstra and AFAIK no one has really challenged it but just taken it as read. ...
    (comp.arch.embedded)
  • Re: C and MISRA, blues... (arithmetic shifts)
    ... learning to write code is good practise, but it's very useful in a ... Avoiding "goto" means avoiding unstructured design (i.e. using only ... In those cases you need to deviate and be able to ...
    (comp.arch.embedded)
  • Re: C and MISRA, blues... (arithmetic shifts)
    ... practise, I then showed my colleague my copy of K+R which basically ... Avoiding "goto" means avoiding unstructured design (i.e. using only only ... not subject to normal peer review on the basis of his, errr, "adherence to ... I see this a lot - crap coders are crap coders, ...
    (comp.arch.embedded)
  • Re: slightly OT: error handling conventions
    ... >> you can always design the code so that there is no ... No emulation of goto is needed when the design is clean and fine. ... At that time we had functions with about 2 screens in ...
    (comp.lang.c)