61–70 of 150 posts
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…
Earlier quoted context omitted.
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?
Once you have your two ifs at the same indent, the indenter can use that info to keep them at the same indentation level. It could even assume you mean (a&&b) vs (!a&&!b) and not the three-way (a&&b), (a&&!b), (!a) when you follow it with an else block (I think that would be the best heuristic)
Implementing this will get a bit hairy, but if you are writing an auto-indenter for C, you should be used to that.
So, all you would have to do is hit one extra backspace to signal your intent.
Alternatively, one could type
if(a) if(b) {
if(a)
if(b) {
ret = 0;
Why?
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.
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.
Good luck using an auto formatter on a code base that uses this technique.
I believe that the layout of code is done by humans for humans. An auto code formatter destroys all of that meaning. I blogged about this more here: http://www.databasesandlife.com/do-not-use-automatic-code-re...
Also, your formatter looks pretty brain-dead. clang-format formats all of those cases (in C++) as in your green examples with Google style turned on. Even the Eclipse formatter should do a better job than what you've posted with the appropriate settings. When I advocate an auto-formatter, it doesn't make sense for you to respond with a blog post talking about a formatter seemingly designed to make everything worse.
Earlier quoted context omitted.
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.)
Earlier quoted context omitted.
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?
An auto-indenter could easily detect the idiom if hit backspace after the auto-indent it produced after the first 'if'. Once you have your two ifs at the same indent, the indenter can use that info to keep them at the same indentation level. It could even assume you mean (a&&b) vs (!a&&!b) and not the three-way (a&&b), (a&&!b), (!a) when you follow it with an else block (I think that would be the best heuristic) Impl…
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.)
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.
Honestly, even if you had to hit an 'expand this statement' button in your debugger to see `if x() && y()` spread into:
x_val = x()
if x_val
y_val = y()
if y_val
...