C style (break, continue, etc.)

[Dick Dunn]

> Some of us feel the same about breaks as we do about gotos. I won't use it, or
> continue either, and I won't let anyone in my shop use it. It is just a goto
> with an implicit label,...

...as are if, while, and for.  So I won't let anyone in my shop use any of
these--but I don't make the rules in my shop for anyone but myself, and I
long ago stopped listening to my own babblings...

Geez, am I trying to one-up a ":-)" or what?  Of course these other
structures are goto's with implicit labels--taking the label out of the
programmer's hands is a way to get some control over the flow structure.

> ...The only way I will
> use a break is in a set of macros implementing a middle exit loop construct.

Well, now we know that this cat's either got some impressive coding
techniques or doesn't use switch statements.  There are only two uses of
break, namely to exit the middle of a loop or to get out of (and usually
terminate) a branch of a switch.  If switch is used without break, I'd like
to see how the coding works.  Other than that, using break only to get out
of the middle of a loop is fairly unspectacular(!).

> We use LOOP...LOOPUNTIL...ENDLOOP. I know, adding features to a language with
> #define has problems, but at least that code is readable once you know what the
> constructs do, which is quite apparent.

OK, great,
	#define	LOOP	for (;;){
	#define	LOOPUNTIL(x)	if (x) break;
	#define	ENDLOOP	}
or some such.  That was a 20-second exercise in turning three items that
any C programmer will understand into three items that he'll have to guess
about or look up somewhere.  If it is not a tautology that "code is (in
some iffy sense) readable once you know what the constructs do", it is at
least fairly certain that "code is not readable until you know what the
constructs do"...and that diddling the language doesn't decrease the number
of constructs.

> C should have that structure built in.
> Since it doesn't, we add it...

Few people who study programming languages seem to understand the idea of
"conceptual consistency" (or integrity).  The pieces of a language have to
hang together.  You can't just twiddle one tiny part of the language to get
rid of your pet peeve and say, "See, I fixed that."  Any change has to fit
in with the overall level of abstraction, spirit, notation, idioms, etc.,
of the language.  Consider, in the given example, that ENDLOOP is a totally
idiosyncratic way of delimiting a statement; all other forms use {}.

Conceptual consistency is what makes languages like C, Pascal, and Icon, as
different as they are, good languages.  It is the reason that they can be
described by small, readable books.  It is the reason a programmer can hold
most of the necessary information about the language in his head rather
than wearing out a manual as he works.  The lack of consistency in
languages like PL/I (to choose an extreme case) leads to big manuals, huge
compilers, and extreme job security for the language's weenies.

It is moderately difficult for a small group of very skilled people, working
together in one place, sharing thoughts and ideas, to produce a good,
consistent language which admits effective implementation and use.  The
idea that a few hacked macros and ad-hoc (??ad-hack??) rules can
noticeably improve the esthetics of a good language is somewhat akin to
the idea that initials carved with a dull knife can improve the esthetics
of a tree:  It's pretty unlikely, but it won't stop people from trying.

> (-: Someone challenged me to produce flames. This should do it :-)

Only if we take you seriously--but it's entertaining in any case.  I guess
I did get in a small flame there at the end.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...If you plant ice, you're gonna harvest wind.