Help required

I disagree. I haven't used a GOTO in C or any other language (other than BASIC, which doesn't count!) in about 25 years.

And (in response to another poster), no, avoiding GOTOs needn't result in hard-to-read code. It just makes you think a bit harder about why the bit you're breaking from is so deeply embedded in the first place, and why perhaps e.g. a state machine might be a better mousetrap.

Steve

You weren't getting flamed (much). We're merely in a discussion of the [de]merits of the goto keyword in C, and I was sharing a bunch of experiences on a piece of code (not yours) in which "goto" barely registers on the sin scale vs. the horrific errors and hairiness.

I can proudly(?) say I've never typed "goto" into a C source file. I have, however, maintained code using goto and not removed it, which I guess is much the same as the difference between murder and manslaughter.

;)

Fairly recently I had to deal with some code written by a company's "Linux" expert. His main() function had several thousand lines and 30-odd GOTOs. Sigh.

Steve

I didn't exactly miss it. First off all, three strikes is Out, so no need to look any further. Second, I did say I was not even looking at the inline asm part of that work of ... well, let's be generous and call it "art".

Outside the IOCCC and possibly some *very* serious case of attempted security by obscurity (say, a copy protection scheme for a millions-of-dollars product), there cannot possibly be any reason for such code to exist.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

This is a symptom of trying to solve the problems of colonels, lietenants and sergeants in a single function, instead of splitting them to separate functions.

Back to drawing board ...

--

Tauno Voipio
tauno voipio (at) iki fi

Maybe so, but some people deserve to receive continued beating even when they are down on the ground unconscious.

:)))))

"Never ascribe to malice that which can adequately be explained by incompetence".

It's surprisingly difficult to get rid of people. This person has _potential_ but needs severe flogging in order to realize it.

I'd say it's a symptom of being clueless ;).

There was much duplication - same code with different magic numbers (aaaargh!). I would have suggested factoring, but became convinced it was a lost cause, and wrote my own code instead...

Steve

I take it you've already put out the order for a sturdy LART (L??er Attitude Readjustment Tool, a.k.a. clue-by-four) to be shipped to your office, then?

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

It's kinda scary. I deal/have dealt with any amount of coders, but have only once or twice run into people who write "good" code - not just by my standards, but by *any* standards. I've worked in R&D departments where my style of coding (defensive, structured, OO/highly-modular, and as clear as possible) has been referred to as "fastidious" (their term: I prefer "thorough"). Yet the fact that I get the project finished sooner and with fewer (if any) bugs seems lost on them. I would have thought that would be the one true metric, but hey...

Actually, I'm being slightly unfair. One tech director *did* notice this, and invited me back to indoctrinate the R&D dept and to co-write [1] a coding standards proposal. Very brave of him, I thought. I failed miserably. I rapidly realised my only hope was to sack the entire team, and start recruiting from scratch. Which was not an option.

[1] I knew I was in trouble when my co-writer, a senior employee, *insisted* on testing Boolean variables for equality with TRUE and FALSE. For example:

a) if ( boolean_variable == FALSE ) b) if ( boolean_variable == TRUE )

I did try countering with:

a) if (( boolean_variable == FALSE ) == TRUE ) b) if (((( boolean_variable == TRUE ) == TRUE ) == TRUE ) == TRUE )

To no avail. I also tried to explain that while FALSE == 0 was reasonable, TRUE == #some_fixed_value was not. I also tried pointing out the many examples in K&R where non-zero means TRUE. I was told the issue was non-negotiable. I walked.

Summary: in hardware, schematics are subject to peer review simply because colleagues have to read the schematics. Not necessarily so with software. I've become a big fan of non-confrontational code reviews for just this reason. It gives me an opportunity to show what good code should look like (and I'm being entirely serious). And I'm always open to ways to improve my own coding - if there's a valid criticism of my code or my approach, I genuinely want to know. This seems to be unusual.

Steve

The advantage to initial factoring is that you have whatever tests applied to the original available, or you can even develop some easily run regression tests. Then you can factor things out one at a time, with a built in curb on your enthusiasm. That also means you postpone the temptation to add features until the factoring is complete.

I have found this especially attractive when the original was written by someone who understood the problem well, but was totally clueless about how to program it. You can learn a lot from a clueless program.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: 
Also see

I have a tool on my wall called "the Motivator". It consists of about a foot of [PLCC44] IC tube with about two feet of multicore cable attached to the end. The cable was the tail of a Microsoft bus mouse, I think. The last foot of the cable has the outer insulation removed and the cores inside spread out. It's a cat-o-five-tails.

An empty tube from 300-mil DIPs is good for swatting a big high-spirited dog on the flanks. It doesn't have enough mass to hurt them, but it makes a loud noise, which gets their attention and which they really don't like.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

I agree, goto can save loads of memory and improve readability of code. I also agree however, that indiscriminate use of goto can drastically reduce the readability of code.

If goto was that bad then it would have been removed from the Ansi standard.

This is quite a common myth. The only time I've found it to be true has been when the code was poorly structured in the first place.

Steve

No myth........ an example would be where there is specific cleanup tasks before a function returns. If the function is needs to return because of a fail condition. Yes there are other ways of doing it, but a goto is easier to read and saves duplicating code.

void Fuction() {

if (!CarryOutSomeTask()) goto ExitFunction;

do; some; actions;

ExitFuction: do; some; cleanup; that needs done; regardless; of success; }

We have something similar at work that we call "the Productivator".

Kelly

EggNChips scrobe on the papyrus:

That is complete bull...t. It's very difficult to spot the '!' in the conditional. A typical example of negative thinking.

void Fuction() { if (CarryOutSomeTask()) { do; some; actions; }

do; some; cleanup; that needs done; regardless; of success; }

would be the correct way to write that code.

--
John B

My solution(s) would be (IMHO) easier to read, easier to expand, and would have no duplication.

1) Break it down vertically. Maintain a flag that means "cleanup required". Skip any other actions if flag is set. Equivalent code to yours (with no need for a flag in this instance) would be:

void Function() { if ( CarryOutSomeTask() ) { actions; } cleanup_actions; }

2) Use a state machine, and put it in a loop. A fairly classic case would be an input stream parser; far too many times I've seen errors handled with GOTOs. Using a state machine allows all the error handling to be put in one place. Changing state to the error state is logically equivalent to a GOTO, but far cleaner, and far more expandable. Rather than thinking in terms of sequences with exception, think vertically. 3) Etc etc.

There are *always* better ways of coding than using GOTOs. These other ways are always more expandable, more readable, have fewer side effects, and reflect more directly the problem you're addressing.

FWIW: I've done a great deal of legacy-code cleanups. I've never had any trouble eliminating all GOTOs, and I've often removed latent bugs and side-effects in the process. I've been doing this stuff long enough to remember when "structured programming" was considered a fad; I think those days are long gone. At first I ran into cases where I *thought* I needed a GOTO; with experience I realised I just hadn't thought the problem through far enough. Nowadays I recognise such cases as meaning "restructure".

GOTOs may be legal, but they promote bad habits and wooly thinking. Avoiding them makes you think more in terms of modularity and generality. This is A Good Thing. And no less a luminary than Dijkstra had something to say on the subject:

Steve

I have had cases where the only way to get the compiler to generate optimal code for a simple memcpy type loop was to use a goto. Using any other looping structure generated very non optimal code. Other (better) compilers generated the same code from a while loop as from the code using gotos. I do agree that if one uses gotos to break out of very convoluted code, then there is probably something wrong. Another use for gotos is writing fast byte interpreters on gcc, where calculated gotos can help a lot.

Regards Anton Erasmus