Live data from Hacker News

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

computationallyendowed.com

11–20 of 150 posts

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

#11
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 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.

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

#12
One 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:

  if (null != foo) { bar(); }

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

#13
I often use: if (false) { } else if (something) { } else if (something) { } To get some indentations right.

When constructing UI elements in code, I used to scope copy/pasted blocks: { Button button = xxx; // and some more }

{ Button button = xxx; // and some more but different }

In the rubydays it'd be: Button.new do |b| something end

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

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

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

#15

Earlier quoted context omitted.

I don't think it really improves readability. All the programmers are familiar with && and ||, and using something else will just confuse people. Also, it's not really that hard to #define it yourself, instead of using includes.

I definitely wouldn't use them because they are unfamiliar. However, in my head I pronounce "&&" as "and" and "&" as "bitand", so using and/bitand over &&/& would reduce a depressingly not-uncommon typo for me. However, on balance, not worth it to me. Note that in C++ they are keywords which is superior to macros.

How are they superior?

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

#16
post #12

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

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

#18

Earlier quoted context omitted.

I definitely wouldn't use them because they are unfamiliar. However, in my head I pronounce "&&" as "and" and "&" as "bitand", so using and/bitand over &&/& would reduce a depressingly not-uncommon typo for me. However, on balance, not worth it to me. Note that in C++ they are keywords which is superior to macros.

How are they superior?

For one, a macro "and" would prevent you from using "and" as the name of a struct field, while a keyword will not. Error reporting will be better too. The differences don't seem all that big though.

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

#19
post #11
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 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.

With visual studio and c# you can put a break point at a certain point in many expressions and while in the debugger you can have it evaluate expressions individually when hovering with the mouse.

Stack traces, however, are still line based and thus if an exception occurs (like null reference) you only get the line, not the statement.

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

#20

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

I believe that the layout of code is done by humans for humans. An auto code formatter destroys all of that meaning.

I blogged about this more here: http://www.databasesandlife.com/do-not-use-automatic-code-re...

Post reply on HN