The Gish source code does that too.
Ifs and &&s and Plan 9's Source Code
111–120 of 150 posts
Re: Ifs and &&s and Plan 9's Source Code
#112How 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 same file\n", an, bn);
ret = 1;
}Re: Ifs and &&s and Plan 9's Source Code
#113One downside to non-braced conditionals is that a semicolon accidentally placed after the conditional will cause the block to always run, e.g.: if (null != foo); bar(); This is valid code in C and Java, and bar() will always run in this case. Having seen people waste hours on such a semicolon, I always use braces, even in one-liners, because I never know when someone is going to break it out into multiple lines later…
I was going to say that a compiler should issue a warning for this, as you'd almost never want a semicolon right after an if condition, but to my surprise Eclipse doesn't seem to flag it. It does however indent the line after the semicolon to the same level as the if, which is at least a red flag that something is up, if you are used to how the auto-indenting normally works.
Both clang and gcc warn on "if(1);", clang by default, gcc with -Wextra. clang also warns on "while(1);" - I think this is somewhat obnoxious, since it can be useful, and would prefer if it only warned if the semicolon was followed by an opening brace, but YMMV.
Re: Ifs and &&s and Plan 9's Source Code
#114This 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 is a detail which boggles my mind. why are our debuggers still line based? they're clearly not in every respect since you can basically always 'step in'to an && sub-expression, but nothing displays progress as you step through such things, nothing lets you put a breakpoint at some sub-expression, nearly every feature of every tool is delineated by lines as if they're the important part of a program.
I've worked with debuggers that allow you to step the short-circuit operations.
That said, a huge cascade of them is something I try to avoid. Two or three, okay. Nine or ten, break it up and make it clear and readily debuggable.
Re: Ifs and &&s and Plan 9's Source Code
#115In ruby, the equivalent to a switch (confusingly called case) can take no initial-compare field and basically become a chained-if that lines up nicely (or more nicely than elsifs). I prefer the visual look of it, personally, but it seems that a lot of people find it too confusing.
As an example:
case
when (a == 1)
dosomething
when (b == 2)
dosomethingelse
when (c)
orthis
else
awww
endRe: Ifs and &&s and Plan 9's Source Code
#116Earlier quoted context omitted.
Because something you do relatively early in the compiler is throw away all of the structure of the source, including flattening nested expressions into a linear IR. Mapping back to line numbers in the debugger is a bit hacky to begin with, and mapping back in an even more fine-grained way would be more complex still.
True (currently, I see no reason this is a necessary step), but that suggests you could perform trivial expansion of lines like `if (a.what() && b == c && (d == f || d exact same hack to get those pseudo-lines into the final stages, and into your debugger. You could even explode each piece into extra variables, so you can see the results of `a.what()` without re-evaluating it. Honestly, even if you had to hit an 'exp…
Even more beneficial, it would give you a much better idea of what, in fact, the computer thought you meant. Seeing a complex nested structure flattened out would give you a more visual indication of what's going on, allowing you to spot misunderstandings earlier.
Re: Ifs and &&s and Plan 9's Source Code
#117Earlier quoted context omitted.
It does if you use the One True Brace Style: http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS since your eyes would flag: if (null != foo); { bar(); } as badness. [edit: correct } to {, ta]
As someone who programs in Go a lot these days, that line (I assume you meant the first curly to be { and not }) looks less obviously wrong than it would have in the past when I did more C/C++ programming. Because I've gotten used to Go's support for short assignment in an if, the semi doesn't look completely out of place there (though the construction here is not valid Go either).
Fortunatly for Go, `if (1); {}` will not compile.
Re: Ifs and &&s and Plan 9's Source Code
#118Earlier quoted context omitted.
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; }
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;
}Re: Ifs and &&s and Plan 9's Source Code
#119Have some fun unit testing that! ha
Re: Ifs and &&s and Plan 9's Source Code
#120And what's the alternative for if(A && B){ x(); }else{ y(); }? Seems very easy to shoot yourself in the foot with this approach.
Here, the x() and y() are assignments, so it's easy:
ret = 0; //y()
if (A)
if (B)
ret = 1; //x()