condition convention 'if (10 == j)...'

[Alexis Dimitriadis]

>> > To prevent silly mistakes like 
>> > 	if (j = 10)
>> > I usually write
>> > 	if (10 == j)
>> > By putting the constant first, I ensure that the compiler will catch the 
>> > typo.
>> 
>> I think this is a good idea.  Any criticisms?  The only problem
>> I have with it is that I am not accustomed to reading code written
>> this way.

>What do you mean, any criticisms?  This is one of the most ugly
>perversions of C I've ever seen!  

  I think it is a great idea.  Congratulations to the original
poster for coming up with a construction that underscores the distinction
between assignment and comparison, (the left side of an assignment must
be an lvalue), while still being legal C, simple, no harder to write,
and easy to understand.  

  If it wasn't done this way to date, it is surely a historical
accident.  To use the common example, I am sure the construction `a += 5'
seemed ugly to the C programmers of yore, but it is now standard
practice.  (With a little help from the dictatorial compiler writers, of
course).

>I tend to read this in terms of
>"if variable equals constant" and try to figure out how the value
>"10" is ever going to change!  YUCK YUCK YUCK!!!!

  If you expect j to change when you read `if (j == 10)', then you are
sorely in need of ways to differentiate between assignment and
comparison!!!

>People that write "if (10 == j)" probably also write "while (1)".
>What do you mean, "while 1"???  Are you expecting "1" to change???
>Everyone knows this should be written "for (;;)", read "forever".

  What, are you expecting "" to change when you write `for (;;)'? (:-)
The for loop chould be preferred since it is the standard idiom, but
there are GOOD reasons to use (constant == lvalue).  (Would you argue
against do ... while loops simply because while loops are more common?)

Respectfully,
 Alexis Dimitriadis
-- 
_______________________________________________
  As soon as I get a regular job, the opinions expressed above
will attach themselves to my employer, who will never be rid of
them again.

	  alexis @ reed
	...ihnp4!{harvard|tektronix}!reed
	...decvax!tektronix!reed
	...teneron!reed