4 ms·

I'd break this up by lines, every time. int result = systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) if (result != 0) S

by T-hawk 7y ago

I'd break this up by lines, every time. int result = systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) if (result != 0) Separation of concerns. Each line does one thing. Making a system call and branching on its result are two separate tasks.

bbmario 7y ago
By that logic, shouldn't you be creating a var for the expression_argument() return?
- T-hawk 7y ago
  Indeed I probably would, just didn't want to distract from the central point in that post.
  - wruza 7y ago
    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.
skissane 7y ago
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 T-hawk 7y ago

bbmario 7y ago

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

T-hawk 7y ago
Indeed I probably would, just didn't want to distract from the central point in that post.
- wruza 7y ago
  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.

skissane 7y ago

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.)