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.
Ifs and &&s and Plan 9's Source Code
11–20 of 150 posts
Re: Ifs and &&s and Plan 9's Source Code
#12 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
#13When 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 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
#15Earlier 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.
Re: Ifs and &&s and Plan 9's Source Code
#16One 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…
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
#17Re: Ifs and &&s and Plan 9's Source Code
#18Earlier 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?
Re: Ifs and &&s and Plan 9's Source Code
#19This 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.
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
#20Good luck using an auto formatter on a code base that uses this technique.
I blogged about this more here: http://www.databasesandlife.com/do-not-use-automatic-code-re...