Hacker News new | ask | show | jobs
by layer8 393 days ago
I disagree that it’s more explicit. The case distinction and the loop and the puts are exactly the same in both code variants. You can replace the ternary operator by an if if that’s bothering you, that wasn’t the point of the change. The point is to first determine what should be output repeatedly, and then to output it, because the output logic is independent from what is being output (in particular, `yes` and `yes y` should be guaranteed have identical behavior). I don’t really see what’s non-explicit about that. Rather to the contrary, it makes it explicit that the output logic is intended to be independent from what is being output.
1 comments

How about:

  for (;;) {
    if (argc > 1)
      puts(argv[1]);
    else
      puts("y");
  }
?

You said "it’s about duplicating logic that should inherently be the same", but that is exactly how it is more explicit, by having this duplication. I assume your problem is with the two "puts()"?

Your proposal is a bit better than the original, although it still duplicates the puts (imagine a variant where you’d want to handle I/O errors), and some will be bothered by the fact that the same unchanging condition is being retested in each loop iteration (the compiler may even warn about it).

But still, I don’t see why you wouldn’t first name what you want to output before starting the outputting. If anything, I’d place the whole output loop in a separate function and have two calls to that function. Nevertheless, it’s even better to express in code the fact that the program doesn’t want to make a distinction between a literal “y” and an argument “y”, by consolidating them into the same variable.

Another way to do this would be to have a static default argument array containing the “y”, and for example having:

    if (argc <= 1) { argv = default_argv; }
    for (;;) { puts(argv[1]); }
This would make explicit the fact thst the argument-less invocation is merely a shortcut for an invocation with an argument and doesn’t otherwise provide any new or different behavior.

Though I think the separate variable (what) is clearly preferable.

I have made the decision to use your "what" method many times before, but in this particular case I do not see the reason to do that, and perhaps this is what I have an issue with. There are many cases in which I would definitely use "what".
That's a whole lot less efficient than both other options, the condition will be checked at every loop, that's not cheap
Oh, I know. :P