Re: C and MISRA, blues... (arithmetic shifts)
- From: "Richard Phillips" <raphillips@xxxxxxxxxxxx>
- Date: Sat, 26 Apr 2008 10:44:28 GMT
Steve at fivetrees wrote:
"Richard Phillips" <raphillips@xxxxxxxxxxxx> wrote in message
* 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.
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
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!
(another 2c poorer)