I keep one-line blocks unbraced when possible and my reasoning is definitely not to feel like a tough macho man. It's more like a mild form of OCD where any syntax that's not necessary just bothers me if I don't omit it.

Reductio ad absurdum: I assume your variable names are single-letter, your Python is indented only one space per block level and every C program is a one-liner? You should check out the Code Golf stackexchange; you'd do well.

Kidding aside, I can appreciate your feeling of OCD (I fight that urge too) but remember that most syntax is for humans, not machines. Using braces communicates intent to the reader; omitting them offers an opportunity to stumble.

Nah, humans go by indentation anyway. Just use whatever brace style you like, but make sure you have a linter / formatter that makes sure your indentation agrees with your braces.

I'm with you on that.

The one line version isn't prone to goto fail, and to me reads very nicely.

    if (x == 1) return;

The two line version, however, I avoid like the plague.

    if (x == 1)
        return;

In Rust the {} are mandatory, but you don't need the (), so you can just write this:

    if a == b {
        stuff();
    }

Thank $whatever for that. Go rust. Sanity prevailing.

I use unbraced blocks as an unwise habit brought over from Pascal, which I learned before C.

I think of these things not as "blocks" but as "statements" -- those can be sandwiched between begin/end or else be one-liners. Pretending that one-liners aren't statements doesn't make any sense at all.

The rules of C are the same -- except it doesn't work as well in practice. Because (1) explicit `{...}` in a one-liner is far less painful than explicit `begin...end`. (2) errors caused by a missing `{`, `}` are harder to spot than errors caused by missing `begin`, `end`.

That said, the best syntax I know of for this is indentation based -- then the whole issue just goes away.

I hate to be that person, but your extra two characters version is only slightly less prone to errors than the one that you are replacing. At the very least, if you are going to insist that these be required, the closing has to be on its own line, or you lose much of the benefit.

And, while I do agree it is easy to vilify this style of statement, I question hating on it. I have found reading code like this is somewhat easy to read if you have internalized reading it to be "if this, then do a single thing." Where the "a single thing" is different from the normal reading of "if this, then that."

Still, I support style guides that prohibit this.

Much to easy to read over, much less likely to get syntax errors on a merge tool mistake, internalise all you like to make fewer mistakes and still don't do it and there will be fewer mistakes. Even if you're so amazing you could never make that mistake yourself a future maintainer might, a tool might and your benefit for taking that risk is zero.

I hate it because it's just so silly. Do we use a feature that has no benefit and carries risk? Do we really need a statistical analysis for this one?

Syntactic noise matters. You don't notice how much it costs until you're used to a lots-of-small-functions style in a language where that's possible.

I prefer consistency in the opposite direction, like I have in Scala: all constructs can be written as expressions. Function body? Expression. Try/catch body? Expression. Loop body? Expression. If you want to put a bunch of statements in rather than an expression, then you put them in braces. (But most of the time there's a better way to express what you wanted).