Until you repeat that code pattern 10 times in one function. Then, do you reuse the same result variable? Or have 10 result variables each with a different name? Or put the whole thing in a block to limit that variable to the scope of that block?

In the past, I've done things like this:

  #define TRY(exp) \
     do { \
        int TRY_result = exp; \
        if (TRY_result != 0) \
           return TRY_result; \
     } while (0)

And then instead of the above I can just write:

     TRY(systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)));

(Sometimes, one wants more complex error detection than just comparison to zero, or more complex error handling than just returning the result code. Often, it is possible to build a more complex version of the above TRY macro to meet those specific requirements.)

By that logic, shouldn't you be creating a var for the expression_argument() return?

Indeed I probably would, just didn't want to distract from the central point in that post.

I would agree with your style, unless all monitors and our vision were built to be more ultrawide-aware than “ultrahigh”. Irregardless of resolution, we can have at most 50-70 lines per eyesight and I doubt that constraint cannot be left unconsidered without losing readability. But it is just my guess from observations, not a real science.

Did you compare writing in different ways and reading it later? This specific style confuses me the most, because I have to mentally connect an assignment with a flow control, because there is no guarantee that a following if() will not use a different variable or it was not shadowed, misnamed, etc. And given that, at once I see x2-3 lines less than usual.