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

[Alexis Dimitriadis]

>>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.

>
>Just that instead of writing, in the traditional manner,
>	if(pc=malloc(nbytes)==NULL)...
>you have to insert extra parens if you use the other form:
>	if(NULL==(pc=malloc(nbytes)))..
>This is because == has higher precedence than =, and the expression will
>first evaluate NULL==pc, then try to set the resulting constant to whatever 
>malloc() returns (except, of course, the compiler doesn't let you get that far).
   Umm, are you SURE about this example?  My compiler assigns operator
precedence regardless of the left-to-right order of the operators,
which is relevant only among operators of the same precedence.  And I have yet 
to hear of a compiler that doesn't.  In fact, pc=malloc(bytes)==NULL 
sets pc to 0 or 1, depending on whether malloc() succeeds.

  At least using NULL==... lets the compiler catch the error.  This 
(constant == lvalue) thing sounds more attractive all the time.

  I guess the reason everybody uses (lvalue==constant) is BECAUSE it looks
like the lvalue=constant construction.  But given the frequency with
which the similarity leads to mistakes, it may be time to get used to
forms that stress the dissimilarity of the operations.  Then there is
less of a chance that a wrong expression will be a valid C construction.
Besides, such constructs can be less ambiguous (easier to read) if used 
consistently, since idioms for different things will look different.

PS. Should customizable pretty printers have a option to move constants
to the left/right of comparisons? :-)

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