Braces don't prevent you from using single-line if:

  if (ptr) { call_oldschool_thingy(ptr); }

many people use specific styles for where to place { and } (e.g in a line by itself) so this might look 'ugly'

Nothing prevents them from not using single-line ifs.

Meshes perfectly fine with one true brace style

Both Rust and Golang have optional parens and mandatory braces, so for the same number of keystrokes one would have something more like:

    if ptr { call_oldschool_thingy(ptr) }

(Keystroke count isn't an important metric for me, but apparently very important to some people.)

I love this style. Braceless style always breaks when refactoring or adding/removing debug logging – so it makes sense to make the braces mandatory. And then, because you have a delimiting if and the starting brace, you don't need to have the parenthesis. Great!

Now if only Rust supported the elision of ; ... (Yeah, I know that they have a reason to not do that, but I don't buy it.)

I've never met a C or C++ debugger that handled this case nicely, unfortunately. Totally ridiculous, of course, because they could! They just never seem to.

Meeting snippets of code like that when debugging is a constant source of frustration for me, because I have to stop what I was doing, edit the code, rebuild, then get back to where I was. Particularly galling when the code in question is in a commonly-included header, and the subsequent build takes several minutes, and I was on a particularly productive-looking trail.

(The last project I worked on solved (?) this problem by performing so shamefully poorly in an unoptimised build that it effectively didn't work. So you had to debug the optimised build. And so single-stepping at the source level just didn't work properly anyway.)

  >I've never met a C or C++ debugger that handled this case nicely, unfortunately. 

Apparently you never use Visual Studio. It can highlight a portion of the statement on each step (at least it used to)

Last I looked, this only worked for C# (possibly all CLR-based languages...) - but native C/C++ breakpoints were addressed by file and line only.

That's likely because with C#, the debugger can use deoptimization and on-stack replacement to get expressions evaluated in the order they happen in the code, as long as the instruction re-ordering happens only in the bytecode to native code compilation. Even though the debugging symbols just have line numbers, the debugger could potentially regenerate they bytecode to figure out which operations correspond to which expressions.

In C++ optimized builds, you might be jumping back and forth between lines due to the compiler re-ordering instructions, and there isn't an easy way to get back code that's in-order.

Was just discussing this at work. A good compromise would be to allow statements outside of of block-parens only when they are on the same line as the control statement.

IMHO there should be a -W to enforce this so those of us with -Werror on can catch it and burn it with fire.

Here at Google the style guide requires block-parens always.

In the project I work on our style also requires block-parens. Sometimes it feels unnecessary, but it does make up in terms of consistency: it's easy to glance through the code and inspect the conditions only.

I got used to this quite a bit and these days if I write code outside the project I work on, I d sometimes omit the block-parens, but I always add extra indentation to ensure the condition is visually well-separated, e.g.:

  if (condition1 || condition2)    execute_foo1(with_bar);
  if (condition3)                  exectute_foo2();

I'm not sure that expanding your statement to multiple lines is any less "useful". I suppose in certain cases it can make code much more verbose, as one line effectively becomes 3-4, which can make it harder to navigate.

Fairly often there's a whole sequence of this type of calls. For example cleanup of multiple objects:

  if (image) foo_release(image);
  if (label) foo_release(label);
  if (data) foo_buffer_destroy(data);
  if (window) foo_window_destroy(window);

It's easier to see that all objects are being cleaned up when each occupies just one line, as that typically matches the look of the initialization:

  window = foo_window_create();
  data = foo_buffer_create(1, 2, 3);
  label = foo_label_create(window);
  image = foo_image_create(window);

Those if statement should be written using the ternary operator. In my subjective opinion, putting the expression in the same line as the if statement is awful. Objectively it is worse because you create a possibility of certain types of errors, like a hanging statement or similar. Ternary operator doesn't have those.

The second example is missing error checking. So the real code isn't that nice.

My point is that C shouldn't look like Python. Small amount of functionality should be written unambiguously and take a lot of space if necessary. Because of the nature of C, it needs a lot boilerplate, and will take a lot of screen space anyway, but that is not a problem, as we are not coding on paper.

It would be really nice if instead of downvoting, someone could provide a counterargument, or comment on parts the disagree.

I downvoted it to indicate that I don't agree with your preference. I rarely downvote for disagreement, but this was a case where I thought it worthwhile to offer the feedback that others strongly do not share your view. My equally strongly felt subjective personal belief is that single line if statements without braces are fine, but that once a second line is required braces should be mandatory.

I find the single line "if" statement without braces to be clearer and simpler than ternary with a (void) expression, and don't think the downsides are significant. It breaks if you were to add another statement after the semicolon on the same line, but I think that should almost always be avoided anyway.

I do find it interesting that others prefer two-line without braces over the single line approach. I find this one to be more dangerous than the single line. Possibly because with line-oriented debuggers it can be hard to set the right breakpoint?

It's quite possible that others are downvoting because they think you are trolling, and that no one would actually believe the ternary operator to be clearer. I wondered also about your defense of Allman braces, which I didn't downvote because I think it's a good example of how different the others's views can be on what seems obvious. While I think (some of) your views are in the (very small) minority, please keep posting them!

How would you use the ternary operator there? Like this?

    image ? foo_release(image) : 0;

Yes. And cast that 0 to (void), so the compiler won't complain over an unused expression.

Any C programmer will recognize what (void)0 means, do nothing.

Sure, but I find it strange to use the ternary operator and discarding the value. It's not wrong, but I think most C programmers prefer a simple if statement.

I was giving an replacement for the if statement presented above, where both expressions are on the same line.

I'm closing in on year 25 of programming in c, and I still refuse to use the ternary operator.

Does this outweigh the disadvantages? I don't think so.