Ifs and &&s and Plan 9's Source Code • Hacker News Board

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

#51

Post by danabramov » Fri, May 24, 2013, 8:39 PM UTC

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

    using (var outFile = new StreamReader(outputFile.OpenRead()))
    using (var expFile = new StreamReader(expectedFile.OpenRead())) 
    {
        ///...
    }

[1]: http://stackoverflow.com/a/1329765/458193

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

#52

Post by vault_ » Fri, May 24, 2013, 8:40 PM UTC

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…

That's not a debugger though; that's a compiler.

All of the debuggers I've seen are line based with the option of single stepping through assembly.

Hopefully the LLDB people will be able to modernize debugging to the degree that the clang guys have modernized error messages, but that still remains to be seen.

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

#53

Post by jbert » Fri, May 24, 2013, 8:45 PM UTC

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

It does if you use the One True Brace Style:

http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS

since your eyes would flag:

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

as badness.

[edit: correct } to {, ta]

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

#54

Post by [deleted] » Fri, May 24, 2013, 8:45 PM UTC

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

[deleted]

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

#55

Post by barrkel » Fri, May 24, 2013, 8:52 PM UTC

cnvogel wrote: post #46

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…

Doing this stops most compilers putting the index variables in registers, with knock on effects on array indexing efficiency.

Not necessarily a bad practice, but something to be aware of.

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

#56

Post by [deleted] » Fri, May 24, 2013, 8:54 PM UTC

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.

[deleted]

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

#57

Post by dasil003 » Fri, May 24, 2013, 8:54 PM UTC

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

Makes me wonder what the quality of the architecture is on your projects is though. Not that I think coding style is unimportant, but it's all too easy to criticize yesteryear's code with today's style standards and totally miss the forest for the trees. Are you doing work that measures up to the ambition of Plan 9?

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

#58

Post by georgemcbay » Fri, May 24, 2013, 8:55 PM UTC

jbert wrote: post #53

thedufer wrote: post #40

Earlier quoted context omitted.

I don't think braces solve that particular problem: if (null != foo); { bar(); }

It does if you use the One True Brace Style: http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS since your eyes would flag: if (null != foo); { bar(); } as badness. [edit: correct } to {, ta]

As someone who programs in Go a lot these days, that line (I assume you meant the first curly to be { and not }) looks less obviously wrong than it would have in the past when I did more C/C++ programming.

Because I've gotten used to Go's support for short assignment in an if, the semi doesn't look completely out of place there (though the construction here is not valid Go either).

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

#59

Post by danbruc » Fri, May 24, 2013, 8:57 PM UTC

cheald wrote: post #37

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

You would love this: https://feralbynight.googlecode.com/files/FeralbyNightv3_2_b...

11k lines in one file - this is the way it should be done. ^^

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

#60

Post by tzs » Fri, May 24, 2013, 8:58 PM UTC

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

What did you find wrong with the argument names?