Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ifs and &&s and Plan 9's Source Code

computationallyendowed.com

Post reply on HN
Print view View original

101–110 of 150 posts

Re: Ifs and &&s and Plan 9's Source Code

#101

Post by MaulingMonkey »

IvyMike wrote: post #47
phoboslab wrote: post #30

Earlier quoted context omitted.

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; }

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

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;
    }

Re: Ifs and &&s and Plan 9's Source Code

#104

Post by vy8vWJlco »

ebbv wrote: post #31

Oh god that code is fucking hideous. If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again. From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)

You may find astyle and indent personally useful if/when you go hoarse (hackers aren't really known for their conformity).

http://man.cx/?page=astyle

http://linux.die.net/man/1/indent

Re: Ifs and &&s and Plan 9's Source Code

#106

Post by jff »

papsosouid wrote: post #69
ebbv wrote: post #31

Oh god that code is fucking hideous. If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again. From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)

It is always the worst developers who fixate on arbitrary rules because they never developed the ability to read code. Go practice reading code, that's the only way to get better at it.

It's a good thing they didn't use a goto, or this guy might have had an aneurysm.

Re: Ifs and &&s and Plan 9's Source Code

#107

Post by jejones3141 »

slg wrote: post #4

This also provides an advantage when debugging. It will become immediately obvious which condition fails when stepping through the code. That isn't always the case with a long string of &&s.

Ouch. I'm pretty sure that the compiler I worked on 22 years ago could stop at sequence points, e.g. after the evaluation of the LHS of && and ||. (OK, actually it was a superset of those, called "gesornenplatz points" in-house, but that's another story.)

Ignoring the "no space after if/while/for" issue, I'd suspect that code to not have been the author's intent if I just came across it.

Re: Ifs and &&s and Plan 9's Source Code

#108

Post by Groxx »

jlgreco wrote: post #43
slg wrote: post #4

This also provides an advantage when debugging. It will become immediately obvious which condition fails when stepping through the code. That isn't always the case with a long string of &&s.

This also makes individual conditions slightly easier to comment out.

I hadn't considered this before... interesting!

Re: Ifs and &&s and Plan 9's Source Code

#109

Post by a-nikolaev »

justin66 wrote: post #72
barrkel wrote: post #55

Earlier quoted context omitted.

Doing this stops most compilers putting the index variables in registers, with knock on effects on array indexing efficiency. Not necessarily a bad practice, but something to be aware of.

It really is a bad idea, though, for the other obvious reason. It goes from being something any programmer can figure out immediately to something that requires additional thought to understand. The only upside is that it satisfies someone's indentaphobia. No, thank you.

Not really a bad idea, imo. The upside is that you cannot make a stupid typo in these nested loops, which is really easy to do, when you have to write the same thing several times in several places of your program. Also, it is easier to refactor, when the need will be.

Re: Ifs and &&s and Plan 9's Source Code

#110

Post by sbmassey »

phoboslab wrote: post #30
triztian wrote: post #14

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.

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; }

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.
Post reply on HN