#define end_{if|for|while|switch} } Was: Re: #define OR ||

[Andy DeFaria]

>/ hpclapd:comp.lang.c / mark at Jhereg.Minnetech.MN.ORG (Mark H. Colburn) /  8:58 am  Jan 28, 1990 /
>
>As a C programmer, I understand constructs like:
>
>	if () {
>	} else
>		foo;
>	i++;
>
>even if I prefer to brace everything myself.  However, given something
>like:
>
>	IF () THEN
>	ELSE
>	ENDIF
>
>would not exactly be natural.  Remember that what may be clear to you,
>is not necessarily clear, or natural to anyone else because they have
>not had the same experiences or background that you have.

I don't use C on a regular basis but I did feel compelled to comment on the
above.  Do you really think that the much-closer-to-english  IF ..  THEN ..
ELSE .. ENDIF "dialect"  is more unnatural  then if ..  {..}  else {..}?  I
really don't think that it would take any  competent C programmer more than
a faction of a second to comprehend these slight  changes.  And  the latter
form has the distinct advantage of explicitly  signifing the  end of the if
statemtent.  Re-writting your example:

	if () {
		...
		...
		...
	} else
		foo;
		i++;

It   can easily be mistaken that   foo  and i++  are   both executed if the
condition is false.    All I really  did here  is  insert   an extra  <tab>
character and viola...  Very confusing at a glance.   You may argue that "I
would never have indented the i++ in  such  a fashion" but I  have  seen it
done.  If ENDIF is used then you would not have this problem.

	IF () THEN
		...
		...
		...
	ELSE
		foo;
		ENDIF
		i++;

Even with the wrong indentation it is pretty aparent that  foo and  i++ are
not executed on the same "level".

I pretty  much  agree with  the other   critizisms about re-defining  other
operators however everyplace that I have been at has their  own quirks that
the new  programmer must  become accustomed to and  I  feel as  long as the
re-defined adds "clarity" and takes a minimal time  to adjust to then it is
OK by me.