[comp.lang.c] #define end_{if|for|while|switch} } Was: Re: #define OR ||

defaria@hpclapd.HP.COM (Andy DeFaria) (02/08/90)

>/ hpclapd:comp.lang.c / mark@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.

machaffi@fred.cs.washington.edu (Scott MacHaffie) (02/09/90)

In article <660074@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes:
>	IF () THEN
>		...
>		...
>		...
>	ELSE
>		foo;
>		ENDIF
d		i++;
>
>Even with the wrong indentation it is pretty aparent that  foo and  i++ are
>not executed on the same "level".

What about the code
	IF () THEN
		...
	ELSE
		foo;
		i++;
	ENDIF

Are foo and i++ executed at the same level?

What if the define's are as follows:
#define IF if
#define THEN /* start of an if statement */
#define ELSE else
#define ENDIF /* end of an if statement */


				Scott MacHaffie

Glenn.Caleval@f72.n140.z1.FIDONET.ORG (Glenn Caleval) (02/15/90)

 > >       IF () THEN
 > >       ELSE
 > >               ENDIF
 > What if the define's are as follows:
 > #define IF if

Mommy, these men are scaring me!

As someone who is just starting out to learn C, and I mean JUST, 
I have been reading this news for several weeks.  Now I'm 
convinced that either I'm not convoluted enough to work in C or 
else you guys are scaring me on purpose.

Scott McHaffie came close to what I have assumed was the 
sensible approach to this issue with the suggestion: 

 > #define THEN /* start of an if statement */
 > #define ENDIF /* end of an if statement */


But why must it be even convoluted to the point that you have 
extraneous "commands" floating around the source code.  If you 
are concerned about saving keystrokes, why not use the keystroke 
macro editors built into most text editors?

In trying to learn the language I have found it useful to 
extensively comment my infant efforts.  To facilitate this I have 
defined keystroke macros such as ALT-I which produces: /*open if 
statement, level   */ <cursor key to space following the word 
level>, and then manually enter what level the if statement is. 
No unknown statements show up in my code, but using these 
macros, almost every line is commented and for my own safety I 
type in manually the levels to keep track of nesting.

Question:  Doesn't this accomplish the same thing or am I really 
missing something here from my admitted ignorance of the 
language?

--  
Glenn Caleval - via FidoNet node 1:140/22
UUCP: alberta!dvinci!weyr!72!Glenn.Caleval
Internet: Glenn.Caleval@f72.n140.z1.FIDONET.ORG
Standard Disclaimers Apply...