Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

computationallyendowed.com

Post reply on HN
Print view View original

41–50 of 150 posts

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

#41

Post by beemoe »

Groxx wrote: post #11
slg wrote: 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.

Very interesting point! There is an argument that lines are a unit of human comprehension and complicated expressions should be broken onto different lines already, as a matter of readability. It makes some sense to let the granularity at which you debug reuse the granularity at which you read.

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

#42

Post by thedufer »

anonymous wrote: post #36
pieguy wrote: post #32

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

Well, you could if (one) { if (two) if (three) if (soon) { stuff }} else { else stuff } Personally, I think I won't have any trouble reading that, but I have noticed I'm somewhat more tolerant than others in this regard. Though I am more OCD than others in other ways.

That doesn't what he's talking about, though. Your else will run anytime `one` is false, not when `one && two && three && soon` is false.

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

#43

Post by jlgreco »

slg wrote: 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 also makes individual conditions slightly easier to comment out.

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

#44

Post by pmarin »

ebbv wrote: post #31

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

I find this code pleasantly readable.

How about this one? http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...

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

#45

Post by xuhu »

anonymous wrote: post #36
pieguy wrote: post #32

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

Well, you could if (one) { if (two) if (three) if (soon) { stuff }} else { else stuff } Personally, I think I won't have any trouble reading that, but I have noticed I'm somewhat more tolerant than others in this regard. Though I am more OCD than others in other ways.

But it's still not the equivalent of: if (one && two && three && soon) {stuff} else {stuff} which I assume the GP meant.

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

#46

Post by cnvogel »

adrusi wrote: post #25

I use this convention often for loops: for (int x = 0; x The semantics are kind of like using a comprehension.

I abhor deep indents, and when I have deeply nested loops that just serve to trivially enumerate things, in C I sometimes add a helper function for the iteration.

e.g. instead of:

    for(int i=0;i
it might become

    i=j=k=0;
    while(all_frob_indices(&i,&j,&k)){
        ....
with all_frob_indices() doing the i++; if(i>N){ i=0; j++ }...

This makes code look more similar to e.g. itertools-constructs in python where you can easily make products, zips, ... from iterables.

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

#47

Post by IvyMike »

phoboslab wrote: post #30
triztian wrote: post #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.

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; }

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

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

#48

Post by pavanky »

thedufer wrote: post #40
rowborg wrote: 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 don't think braces solve that particular problem: if (null != foo); { bar(); }

I agree. This is we do

   if (null != foo) bar();
or

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

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

#49

Post by calebegg »

andkerosine wrote: post #21
jamesaguilar wrote: post #7

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

For what it's worth, Vim handles it just fine.

What? Not for me, not with cindent on. It indents each if statement by one level, just like it "should". How would it somehow know to not indent them?

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

#50

Post by comex »

leoh wrote: post #26
Groxx wrote: post #11

Earlier quoted context omitted.

^ 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 p…

To be fair, that page is severely out of date, and gcc 4.2 was released six years ago. An updated comparison is here: http://gcc.gnu.org/wiki/ClangDiagnosticsComparison

Anyway, those are compiler warnings rather than after-the-fact debugging. I don't think LLVM's debugger, lldb, does any better in this case.

Post reply on HN