Good luck using an auto formatter on a code base that uses this technique.
For what it's worth, Vim handles it just fine.
Ifs and &&s and Plan 9's Source Code
21–30 of 150 posts
Re: Ifs and &&s and Plan 9's Source Code
#22It 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.
3 tabs? is there a language, community or editor that encourages this convention? usually the default for tab is 4 or 2, and 4 is the PEP convention for Python, while 2 is very commonly used around Ruby as far as I have seen.
btw there are no tabs specifically because it's meant to be read as a single statement, not nested conditions.
Re: Ifs and &&s and Plan 9's Source Code
#23One 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.
Absolutely, indentation helps catch this when writing.
When I've seen this happen, it wasn't because of a semicolon added when the code was written. It was someone accidentally adding a semicolon to a line later, without realizing it. Unless they then went to the next line and hit the "fix indentation" key, they didn't catch it.
Re: Ifs and &&s and Plan 9's Source Code
#24This 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.
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.
Re: Ifs and &&s and Plan 9's Source Code
#25I use this convention often for loops:
for (int x = 0; x Re: Ifs and &&s and Plan 9's Source Code
#26This 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.
Not all debuggers are line-based. Many of LLVM's tools give descriptive errors ("expressive diagnostics").
Here's an example of gcc versus clang (a "frontend" for LLVM):
$ gcc-4.2 -fsyntax-only -Wformat format-strings.c
format-strings.c:91: warning: too few arguments for format
$ clang -fsyntax-only format-strings.c
format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument
printf("%.*d");
^Re: Ifs and &&s and Plan 9's Source Code
#27As a side note:
if(b->qid.path==a->qid.path)
Re: Ifs and &&s and Plan 9's Source Code
#28When you use the fact that && is not the logical conjunction, you'd better use another if. if (b != nil) if (b->bla == a->bla) is so much clearer (and language agnostic) than if (b != nil && b->bla == a->bla)
I've never heard about writing language agnostic code in my life, lol!
Re: Ifs and &&s and Plan 9's Source Code
#29Amazing how old C, and still obscure things always pop up here in HN. I had no idea of such idiom.
Re: Ifs and &&s and Plan 9's Source Code
#30How 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.
I still prefer this:
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;
}