[triztian]

How about using this alternative form:

  if((b != nil)
  &&(b->qid.type==a->qid.type)
  &&(b->qid.path==a->qid.path)
  &&(b->qid.vers==a->qid.vers)
  &&(b->dev==a->dev)
  &&(b->type==a->type)){
      fprint(2, "cp: %s and %s are the same file\n", an, bn);
      ret = 1;
    }

It keeps almost the same visual look and it uses the common convetion, except for the && at the beginning of each line.

[phoboslab]

I still prefer this:

  if(
  	b != nil &&
  	b->qid.type == a->qid.type &&
  	b->qid.path == a->qid.path &&
  	b->qid.vers == a->qid.vers &&
  	b->dev == a->dev &&
  	b->type == a->type
  ) {
  	fprint(2, "cp: %s and %s are the same file\n", an, bn);
  	ret = 1;
  }

[IvyMike]

We can go deeper...

  if(
  	b != nil &&
  	b->qid.type == a->qid.type &&
  	b->qid.path == a->qid.path &&
  	b->qid.vers == a->qid.vers &&
  	b->dev      == a->dev &&
  	b->type     == a->type
  ) {
  	fprint(2, "cp: %s and %s are the same file\n", an, bn);
  	ret = 1;
  }

(Lined up the "a"s to make it obvious that they're all the same.)

[MaulingMonkey]

I'd prefer some variation on:

    int samedirfile( Dir *a, Dir *b )
    {
            if( a == b )
                    return 1;
    
            return  ( a && b ) &&
                    ( a->qid.type == b->qid.type ) &&
                    ( a->qid.path == b->qid.path ) &&
                    ( a->qid.vers == b->qid.vers ) &&
                    ( a->dev      == b->dev ) &&
                    ( a->type     == b->type );
    }
    
    ...
    
    if( samedirfile( a, b ) ) {
            fprint(2, "cp: %s and %s are the same file\n", an, bn);
            ret = 1;
    }

[tricolon]

I think it's fascinating that we prefer styles that are almost opposites:

    int samedirfile(Dir *a, Dir *b) {
        if(a == b) {
            return 1;
        }

        return (a && b)
            && (a->qid.type == b->qid.type)
            && (a->qid.path == b->qid.path)
            && (a->qid.vers == b->qid.vers)
            && (a->dev == b->dev)
            && (a->type == b->type);
    }
    
    ...
    
    if(samedirfile(a, b)) {
        fprint(2, "cp: %s and %s are the same file\n", an, bn);
        ret = 1;
    }

[MaulingMonkey]

I'll note I actually have a slight preference for prepended continuation operators like you have, but I stick to the style used at work for the sake of my sanity in trying to write consistent code.

[drivebyacct2]

I'm so, so, so glad that new languages are banning braceless if/else bodies.

[MaulingMonkey]

So how about that python? </trololololo>

[drivebyacct2]

I should have of course said "some" :)

[sbmassey]

Putting the &&'s at the beginning of each line makes the overall shape of the logic expression easier to percieve: you can prove they're all one big 'and' expression without having to hunt for the end of each line.

[Avshalom]

  if(b != nil){
  if(b->qid.type==a->qid.type){
  if(b->qid.path==a->qid.path){
  if(b->qid.vers==a->qid.vers){
  if(b->dev==a->dev){
  if(b->type==a->type){
    fprint(2, "cp: %s and %s are the same file\n", an, bn);
    ret = 1;
  }}}}}}

I will never understand the allergy to multiple braces on one line.

[notaddicted]

I think the aversion is because the way that they line up visually is the opposite of the way that they are matched by the parser. I think everyone needs a dose of LISP to get over any problems they have with any frequency or arrangement of brackets/parens/braces. Anyway, having a function that compares two structs and returns 0 or 1 with a printf out to stderr is just gross in my opinion.

[chj]

Using ifs is definitely more readable than &&, words always win. However carefully alignment of && and ( can make things better. Note that the comment after "if" is necessary to keep the shape balanced.

    if( /* b is same as a */
           (b != nil)
        && (b->qid.type == a->qid.type)
        && (b->qid.path == a->qid.path)
        && (b->qid.vers == a->qid.vers)
        && (b->dev == a->dev)
        && (b->type == a->type)
    ){
        fprint(2, "cp: %s and %s are the same file\n", an, bn);
        ret = 1;
    }

[dllthomas]

"words always win"

Add seven to three then multiply the whole thing by twelve.

(7 + 3) * 12

[dave809]

(mult (add seven three) twelve)

[dllthomas]

Better, obviously, but I think the regular math notation still wins. It's more concise, and equally (if not more) familiar.

[moron4hire]

only if you treat symbols as a foreign language