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

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.

How about using this alternative form:<p><pre><code> if((b != nil) &#38;&#38;(b-&#62;qid.type==a-&#62;qid.type) &#38;&#38;(b-&#62;qid.path==a-&#62;qid.path) &#38;&#38;(b-&#62;qid.vers==a-&#62;qid.vers) &#38;&#38;(b-&#62;dev==a-&#62;dev) &#38;&#38;(b-&#62;type==a-&#62;type)){ fprint(2, "cp: %s and %s are the same file\n", an, bn); ret = 1; } </code></pre> It keeps almost the same visual look and it uses the common convetion, except for the &#38;&#38; at the beginning of each line.

One downside to non-braced conditionals is that a semicolon accidentally placed after the conditional will cause the block to always run, e.g.:<p><pre><code> if (null != foo); bar(); </code></pre> This is valid code in C and Java, and bar() will always run in this case.<p>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:<p><pre><code> if (null != foo) { bar(); }</code></pre>

As an idiom I quite like this form. I often do similar for double iterations:<p><pre><code> for (int x = 0; x &#60; width; x++) for (int y = 0; y &#60; height; y++) { do_something(x, y); }</code></pre>

There is a similar [common][1] idiom with `using` in C#. When you need to create and later dispose several resources, to avoid excessive nesting you write<p><pre><code> using (var outFile = new StreamReader(outputFile.OpenRead())) using (var expFile = new StreamReader(expectedFile.OpenRead())) { ///... } </code></pre> [1]: <a href="http://stackoverflow.com/a/1329765/458193" rel="nofollow">http://stackoverflow.com/a/1329765/458193</a>

I actually quite like that, although usually when I have a large conditional like that I just give it named boolean variables to make it read more like a sentence, IE:<p><pre><code> bool exists = b != nil; bool sameType = b-&#62;qid.type == a-&#62;qid.type; bool samePath = b-&#62;qid.path == a-&#62;qid.path; ... if(exists &#38;&#38; sameType &#38;&#38; samePath) { } </code></pre> It's also a lot easier to inspect in a debugger, as all the conditions appear in the locals list.

As a side note:<p><pre><code> if(b-&#62;qid.path==a-&#62;qid.path) </code></pre> is interesting. This is not how you compare strings in C. So it is either a bug or dirstat() needs to guarantee that different results pointing to the same file always share the path string.

I use this convention often for loops:<p><pre><code> for (int x = 0; x &#60; width; x++) for (int y = 0; y &#60; width; y++) if ((x + y) % 3) { // ... } </code></pre> The semantics are kind of like using a comprehension.

I often use: if (false) { } else if (something) { } else if (something) { } To get some indentations right.<p>When constructing UI elements in code, I used to scope copy/pasted blocks: { Button button = xxx; // and some more }<p>{ Button button = xxx; // and some more but different }<p>In the rubydays it'd be: Button.new do |b| something end

If not for the need to get and later free the<p><pre><code> Dir *b;</code></pre> , and print the message, this condition would get a lot simpler. I'd find it more readable to write a function<p><pre><code> bool samefile(Dir *a, Dir *b) </code></pre> , have it consist of a single-line return statement, and then have the caller just do if (samefile(a, b)) { ... }.

I think the meaning was fairly obvious at first glance, and it read as a sloppy way of conjoining expressions, where &#38;&#38; should be preferred, because it doesn't rely on the arbitrary block rules of if expressions.<p>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 broken, but it <i>still compiles</i>. With &#38;&#38;, it would fail to compile and the error would be caught immediately.<p>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.

Good luck using an auto formatter on a code base that uses this technique.

Great, now add an "else".

In 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.<p>As an example:<p><pre><code> case when (a == 1) dosomething when (b == 2) dosomethingelse when (c) orthis else awww end</code></pre>

In Mathematica the FullForm of a &#38;&#38; b is And[a, b]. You can use this to format long lists of conditions as<p><pre><code> And[ a, b ] </code></pre> You can also rely on the fact that logical expressions are always short-circuited, so False &#38;&#38; Print["won't be printed"], doesn't print anything.<p>Finally, you can put a bunch of conditions in a list and do And @@ list.

C++ has "and"/"or"/"not" etc., so you can do<p><pre><code> if(not A and B) </code></pre> but I'm not sure I've ever seen anyone do it. <a href="http://en.cppreference.com/w/cpp/language/operator_alternative" rel="nofollow">http://en.cppreference.com/w/cpp/language/operator_alternati...</a><p>To get them in C, see the note about iso646.h in the link.

When you use the fact that &#38;&#38; is not the logical conjunction, you'd better use another if.<p><pre><code> if (b != nil) if (b-&#62;bla == a-&#62;bla) </code></pre> is so much clearer (and language agnostic) than<p><pre><code> if (b != nil &#38;&#38; b-&#62;bla == a-&#62;bla)</code></pre>

Oh god that code is fucking hideous.<p>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.<p>From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)

Amazing how old C, and still obscure things always pop up here in HN. I had no idea of such idiom.

Perhaps the compiler wasn't relied upon to provide "short circuit" boolean eval? This code will compile that way no matter if it's available in the compiler or not.<p>Honestly for the sake of being more robust, I'd add if(a != nil) after the first test of b.<p>if(b != nil) if(a != nil) if ...

It's not complex at all. How can it be confusing? I was confused by the author's confusion :-/

My knee-jerk reaction to this post was that this increases the chance of another developer introducing a dangling else manyfold.<p><a href="http://en.wikipedia.org/wiki/Dangling_else" rel="nofollow">http://en.wikipedia.org/wiki/Dangling_else</a>

Hmm, I'm not a fan of an if without braces. It is just begging for someone to come along and stick multiple statements after it expecting them to run when it fires. Heck, maybe even me tired at the end of the day.

It looks weird without tabbing. But if the code was tabbed, then it would take too much space, since they are using huge tabs. That's why I prefer 3-space tabs. Not too small, not too big.

This isn't a new thing. I remember it being used in ZZT-OOP, where you didn't have boolean operators.<p><pre><code> #if foo #if bar #send obj:dosomething</code></pre>

And what's the alternative for if(A &#38;&#38; B){ x(); }else{ y(); }? Seems very easy to shoot yourself in the foot with this approach.

The Gish source code does that too.<p><a href="https://github.com/blinry/gish" rel="nofollow">https://github.com/blinry/gish</a>

I hope everyone realizes that this code was probably written by Ken Thompson or Rob Pike.

This just looks like it was written by someone who's done some logic programming.

Have some fun unit testing that! ha