break, continue, return, goto (net.religion.c)

[Craig Miller]

In article <779 at whuxl.UUCP> mike at whuxl.UUCP (BALDWIN) writes:
>But I do object slightly to the code not being called top-down (structured).
>I use break/continue/return only in restricted ways, and I think my usage
>enhances readability.  Unfortunately, my sample code wasn't vicious enough.

	Well, after rereading Mike's programming examples (the word 'code'
	has such negative connotations... :-), I think I was kinda harsh
	saying it wasn't 'top-down'.  His stuff was readable, especially
	considering some of the abuses I've seen in the past.  Things
	like:

			while (1) {	/* yuck! */
				if (a)
					break;
				if (b)
					break;
				if (c)
					return (0);
				if (d)
					return (0)
				}

	Stuff like this is what I was really aiming at.  The programmer (?)
	in question here seemed too lazy to really think about what was
	going on.  But, "this is my opinion only"...

>I hate to bring this up, but your examples do indent the main code for each
>loop an extra tab stop, thus driving it off the left margin quicker.  A
>trite point, I know, but it matters to me.

	True.  True.  True.  After talking to another experienced C programmer
	here (btw, just because this is a brewery doesn't mean that all we do
	is drink :-), and thinking about it a bit, I came to the conclusion
	that a number of folks out there use breaks/return/continue for exactly
	that reason.  They don't want the program spilling off the right margin
	of the screen.  My response again is that if I find *my* programs
	spilling of the right margin, this indicates I can usually split the
	current function up into more concise functions and just call them.
	And since I use switch() like this:

			switch (something) {
				case A:
					stuff_for_A...
					break
				case B:
					etc.
					break;
				default:
					break;
				}

	I *really* run into such problems. (flames to /dev/null :-)
>
>OK, here are some modified bits of code for you to rearrange:
>

	Well, I could go through all of this, but it's kinda time
	consuming (and long-distance consuming), so I'll pass.  But
	if I did rearrange it, I would try to split up the block
	into separate, concise functions, if at all possible....
	But if you wanted to squeeze it all into the current function,
	I admit it would be hard. (especially on an 80 column terminal!
	Where's my Sun at, anyway? :-)

>Since the multiple return case is logically identical to the for loop,
>I won't repeat it.  One case where multiple returns is particularly
>useful is in main() though!  What about:

	Same idea with returns.  If I have a function that logically wants
	to do a lot of work, I usually attempt to split it up into smaller
	functions, each doing a portion of the work.  Example:

	main(argc, argv)
	int argc;
	char **argv;
	{
		int init(), dothework(), cleanup(), status;
	
		if ((status = init(&argc, &argv)) == SUCCESS) {
			status = dothework(argc, argv);
			if (cleanup() == FAILURE)
				status = FAILURE;
			}

		return (status);
	}

	Something in this flavor (this may be taking it a bit too far,
	but I like to push the real work down as far as possible...)

>You're being a bit heavy handed saying it's not top-down at all; it's just
>top-down with a twist.  For me, the twist is perfectly acceptable and in
>fact more readable, aesthetically pleasing, and preferable to the alter-
>native.  The canonical code is:

	True again.  Like I said once before in a previous style discussion
	(that one was one curly braces, I think), the most important thing
	to me is that you're consistent throughout all of your programs.  If
	you are, I can probably pick it up and read it.  (usually :-)

>Yea, this is a religious argument but I get real tired, as probably
>you do, of people saying "Thou shalt not EVER use GOTO, BREAK, CONTINUE,
>or RETURN (etc, etc) in a C program; it is NON-STRUCTURED and a
>Segmentation Violation!"  And anyhoo, I just *love* religious arguments!
>
>"Hey!  Who tore up all my			Michael Baldwin
> wallpaper samples?"				{at&t}!whuxl!mike

	Segmention violation?  For some reason that reminds of a semi-funny
	thing that happened here.  One of the programmers here, who is
	one of our converted C programmers, I believe, was testing a program
	on our 3B20 here, when she got an EMT trap (which I don't think she's
	ever seen before).  That probably doesn't seem too funny, till you
	realize her login name was 'emt'.  From what I hear, that startled
	her quite a bit. (sorry Elaine, but I had to tell that story sooner
	or later)
	
	Oh well, enough religion.  That's what the C bible is for, right? :-)

			Craig

	Today's C question:  how come C won't let you increment a global,
	static or automatic array name, but will let you increment an array
	name that's a function argument?  Film at 11.
-- 
	Craig Miller
	{*}!ihnp4!we53!busch!dcm
	The Anheuser-Busch Companies; St. Louis, Mo.

- Since I'm a consultant here and not an Anheuser-Busch employee, my
  views (or lack of) are strictly my own.