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

141–150 of 150 posts

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

#141

Post by moron4hire »

chj wrote: post #112
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.

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 sam…

only if you treat symbols as a foreign language

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

#142

Post by pjmlp »

myg204 wrote: post #140
pjmlp wrote: post #137

Earlier quoted context omitted.

I can say the same for many other OSs, like BeOS or Native Oberon, just to name two of them, but in the end it is (1) that counts. It is like football, it does not matter how brilliant a team plays, but which one has higher score when the referee signals the end of the game.

IMHO, (1) is the not only think that counts in the end. A 'failed' (as in (1)) concept may have a second life in future works. Also, in the case of plan9 some ideas did get traction (UTF-8 for example), some didn't so it's not all bad. Comparisons are tricky, you can compare an OS to a football team, and then yes maybe what you say is right. Or you can compare it to a work of art, then what matters is the influence t…

Yeah, maybe I was a bit too harsh.

It is just that I personally never found Plan9 that interesting, except for its successor Inferno and Limbo.

For me operating systems that explore designs done with regards to micro architectures or safe systems programming languages are much more interesting.

So for me Plan9 tends to be just another OS. And yes I have used it.

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

#143

Post by dave809 »

dllthomas wrote: post #131
chj wrote: post #112

Earlier quoted context omitted.

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 sam…

"words always win" Add seven to three then multiply the whole thing by twelve. (7 + 3) * 12

(mult (add seven three) twelve)

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

#144

Post by dllthomas »

dave809 wrote: post #143
dllthomas wrote: post #131

Earlier quoted context omitted.

"words always win" Add seven to three then multiply the whole thing by twelve. (7 + 3) * 12

(mult (add seven three) twelve)

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

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

#145

Post by reddiric »

moron4hire wrote: post #134

I think the meaning was fairly obvious at first glance, and it read as a sloppy way of conjoining expressions, where && should be preferred, because it doesn't rely on the arbitrary block rules of if expressions. Imagine for a moment that a stray ";" ends up at the end of one of those if statements. I don't care how, perhaps you just dropped your Warby Parkers on your keyboard or something. Not only is the code now b…

I think the meaning was fairly obvious at first glance, and it read as a fine way of conjoining expressions, where multiple if statements should be preferred, because it doesn't rely on the arbitrary subexpression evaluation ordering rules of binary operators.

Imagine for a moment that a character ends up deleted at the end of one of those && expressions. I don't care how, perhaps you just dropped your Warby Parkers on your keyboard or something. Not only is the code now broken, but it still compiles. With if(...)s, it would fail to compile and the error would be caught immediately.

The moral of the story is that syntax is your friend, not your enemy. Use syntax as much as possible to catch errors. Especially with strictly-typed languages, you have an incredible tool for automated verification of certain portions of your program. Use it.

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

#146

Post by JadeNB »

cnvogel wrote: post #46
adrusi wrote: post #25

I use this convention often for loops: for (int x = 0; x The semantics are kind of like using a comprehension.

I abhor deep indents, and when I have deeply nested loops that just serve to trivially enumerate things, in C I sometimes add a helper function for the iteration. e.g. instead of: for(int i=0;i it might become i=j=k=0; while(all_frob_indices(&i,&j,&k)){ .... with all_frob_indices() doing the i++; if(i>N){ i=0; j++ }... This makes code look more similar to e.g. itertools-constructs in python where you can easily make…

Notice that your own post illustrates why this is a bad idea; whereas

    for(int i=0;i
correctly steps through `N` `i`-values, a version with your `all_frob_indices` would step through `N + 1` `i`-values (because your termination check is `i > N`). Of course, it's easy to fix this once it's spotted, but you won't spot it with the same ease that you'd spot an off-by-one error in a `for` loop, because your eyes (or at least my eyes) don't know how an `all_frob_indices` function should look as well as they do how a `for` loop should look.

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

#147

Post by moron4hire »

reddiric wrote: post #145
moron4hire wrote: post #134

I think the meaning was fairly obvious at first glance, and it read as a sloppy way of conjoining expressions, where && should be preferred, because it doesn't rely on the arbitrary block rules of if expressions. Imagine for a moment that a stray ";" ends up at the end of one of those if statements. I don't care how, perhaps you just dropped your Warby Parkers on your keyboard or something. Not only is the code now b…

I think the meaning was fairly obvious at first glance, and it read as a fine way of conjoining expressions, where multiple if statements should be preferred, because it doesn't rely on the arbitrary subexpression evaluation ordering rules of binary operators. Imagine for a moment that a character ends up deleted at the end of one of those && expressions. I don't care how, perhaps you just dropped your Warby Parkers…

Lazy evaluation is not arbitrary, it's a well established convention that any sane language implements (thus marking the languages that do not use it as completely insane and unworthy of our effort).

And also, your reply is technically incorrect, a typographical error or any kind is more likely to be caught in the && situation, and the style of reply makes you an insufferable geek.

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

#148

Post by MaulingMonkey »

tricolon wrote: post #118
MaulingMonkey wrote: post #101

Earlier quoted context omitted.

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

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

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.

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

#149

Post by MaulingMonkey »

drivebyacct2 wrote: post #126
MaulingMonkey wrote: post #101

Earlier quoted context omitted.

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

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

So how about that python?
Post reply on HN