Hacker News Reader

Comment by wruza | Hacker News Reader

  if (systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT) != 0)
  if (0 != systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT))

One may find it easier to read/navigate flow control in C code that returns status codes, when these codes are stated beforehand. When there are series of long lines and a mix of 0==success and 0==false, it is easy to get lost, at least in my experience.

View on HN

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.

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.

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

Yeah but that's also just a ridiculously long line which will be hard to read regardless ;)

You either grow it to the right, or in a vertical direction. If the latter, conditions also disperse across that axis. What matters more in a specific case is up to the writer to decide who tries to remain both readable and concise. Highlighting important details in a homogeneous text is part of “the art”.

Reply on news.ycombinator.com