71–80 of 150 posts
Perhaps the compiler wasn't relied upon to provide "short circuit" boolean eval? This code will compile that way no matter if it's available in the compiler or not. Honestly for the sake of being more robust, I'd add if(a != nil) after the first test of b. if(b != nil) if(a != nil) if ...
Earlier quoted context omitted.
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.
The only upside is that it satisfies someone's indentaphobia. No, thank you.
Earlier quoted context omitted.
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.)
[deleted]
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.
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.
On the other hand, an optimizing compiler already makes it pretty hard to single-line-step through a program (what with reordering, CSE, and more sophisticated transforms). Single-expression-stepping would be an even more difficult "debugging illusion" to provide.
Perhaps the compiler wasn't relied upon to provide "short circuit" boolean eval? This code will compile that way no matter if it's available in the compiler or not. Honestly for the sake of being more robust, I'd add if(a != nil) after the first test of b. if(b != nil) if(a != nil) if ...
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…
More seriously, after more than 10 years of writing C, C++ and Java, I've never run into this problem. I still wrap mine out of habit (to prevent this dreaded occurrence), but I think good testing would obviate any need for this.
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.
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.)
Maybe it comes from using Python as my go-to language (and that it's my favorite language) but i personally like to avoid non-essential braces and other minutia. Yes, of course, I know the argument: a one-line bracketless "if" can set-up a future developer for failure if they need to add an item to the conditional block. And if they for some reason decide not to read the actual conditional. And if they don't test it.…
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.
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.
if(b != nil){
if(b->qid.type==a->qid.type){
if(b->qid.path==a->qid.path){
if(b->qid.vers==a->qid.vers){
if(b->dev==a->dev){
if(b->type==a->type){
fprint(2, "cp: %s and %s are the same file\n", an, bn);
ret = 1;
}}}}}}