Hacker News Reader

Comment by Leace | Hacker News Reader

Interesting pattern, first time I saw this:

        switch (true) {
            case cellA > cellB: return 1;
            case cellA < cellB: return -1;
            case cellA === cellB: return 0;
        }

Source: https://htmldom.dev/sort-a-table-by-clicking-its-headers

View on HN

I think you can just do:

    if (cellA > cellB) return 1;
    if (cellA < cellB) return -1;
    if (cellA === cellB) return 0;

Why is the switch better? Or even (less explicit, but shorter code):

    if (cellA === cellB) return 0;
    return cellA > cellB ? 1 : -1;

It makes it clear that you're going to execute only one of the possibilities. Maybe that's clearer than a page full of ifs. But yeah, not particularly fond of the idea.

Except JavaScript switch has fallthrough, so it doesn’t make that clear at all. (Sure, no fallthrough happens with return in each case, but neither would a bunch of plain if ... return.)

hah, well then you can of course continue...

    return (cellA === cellB) ? 0 : (cellA > cellB ? 1 : -1);

Keep going:

    return (cellA > cellB) * 1 + (cellA < cellB) * -1;

    return Math.sign(cellA - cellB);

You don't need the * 1 multiplication:

   return (cellA > cellB) - (cellA < cellB);

does work for NaN... rookie mistake, eh

Math.sign trick doesn't work for strings.

That's true, but the default string comparison sometimes isn't that useful, right? I somehow assumed the data is numbers only, rookie mistake :)

    'ana' > 'Bob'
    '2' > '123'

You usually want to clearly define the order or pre-process the strings in some way (trim them, same casing, etc).

Well, you can pass the strings through .toUpperCase() before comparing them.

Or indeed drop the <, > based approach and use: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Or: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

honestly? i like it. properly formatted it looks alright:

    return (
      (cellA === cellB) ? 0 :
      (cellA >   cellB) ? 1 :
      -1
    );

and it's an expression, so i immediately know it won't do any weird control flow. i'd prefer "if/then/else" vs "?/:" but it's not bad

This works fine if the ? operator is right-associative, but in PHP it's left-associative and you have a subtle bug.

I find a better indendation style for this is more like

    condition
        ? truthy
        : falsy

i use that style too sometimes, depends on what's clearer. IME the former usually works better if you have a multiple tests, but the latter is the only readable option if you need to break a case across lines.

yeah, ternary-if is busted in php :/ (far from the only thing that's busted there though...) i'm actually doing some PHP work right now, and never chain ifs to avoid this exact thing.

Switch statements indicate "it's one of these things", whereas in the series of ifs any of them could be true. Using a switch statement tells the reader that you expect one of these things to happen [0]. Using a series of ifs tells the reader that these things might or might not happen depending, and they're going to have to read each statement to work out which.

Your last version doesn't tell the reader what your intention is at all, and they need to work out what you're trying to do here. It's a lot less readable. Unless you're desperate for those bytes, it'd be better to use the switch statement for this case.

[0]: This gets a little weird in languages like JS where switch statements fall through to the next one if you don't break or return, but generally it still holds true.

I don't think this line of reasoning makes sense, since as you acknowledge, JS switch has fallthrough. I would not immediately assume that the coder's intent was for only one branch to execute if I came across a 'switch' in some JS code.

That's not how switches work: a switch can (and will) trigger lots of cases if you don't either `break` (highly unintuitive to new programmers, who like you believe switch is "do one of these") or `return`, either of which cuts cuts the switch short.

With if you can also indicate "it's one of these things" by throwing an error at the end:

    if (cellA > cellB) return 1;
    if (cellA < cellB) return -1;
    if (cellA === cellB) return 0;
    throw new Error();

Let me tell you about if..else!

Adding 'else's to the above code would make it superior to switch by these metrics (e.g. no fallthrough).

You should not use switch in JavaScript, because it is a language where switch requires break, which means it's 100% going to bite you in the ass unless you have a linter that checks for the break. It's not worth it for such a simple case.

both fragments are incorrect for NaN...

The correct is return a<b?-1: (a>b? 1 :0)

var a=NaN, b=1; a<b ? -1 : (a>b ? 1 : 0); // 0

var a="a", b=1; a<b ? -1 : (a>b ? 1 : 0); // 0

The switch and if statements would return undefined in these cases. Or others threw an error if none of the conditions matched, that would work too.

You're seeing it for the first time because it's a bad pattern. It's confusing to a reader who is expecting a typical switch use-case, and it has no performance benefit over a series of if statements.

I don't know about V8, but a lot of compilers would have a harder time optimizing this because of the strange structure. For mature compilers and naive (i.e. not-yet-profiled) projects, it's better to write what you mean and let the compiler optimize it.

Go does this too, and it's actually OK once you get used to it. The switch statement is still saying "it's one of these things"

I had to think for a sec to get this. And this already makes it worse than 3 if statements. Does anyone really find this more readable?

Coming from a lisp I often wish other languages had `cond` so I don't have to nest if statements. This looks like a poor man's cond.

So yes, I do find this more readable. It makes it clear that only one branch will get executed.

This would be equally clear if the author had just used a sequence of if statements with a 'return' in each one. (Note that Javascript's case has fallthrough, so you can't immediately conclude that only one branch of a case will be executed.)

You don't have to nest if-statements and I would say nested-if is wrong. You simply use else-if. It's a flat structure just like cond.

you mean two if statements. The last case is a default return.

The modern code is:

  return cellA.localeCompare(cellB);

Because cellA and cellB are always strings:

   const cellA = rowA.querySelectorAll('td')[index].innerHTML;

If using a framework, you would generally have typed JSON data, which is better. For example, makes number columns sort correctly (example code above sorts ‘10’ before ‘9’).

Dealing with cells of tables is one area where code optimisations are needed if you care about performance and have a large table. There are multiple obvious problems e.g. looping over calls to querySelectorAll.

That switch(true) statement is not what I would expect from a more experienced developer. It is show-off code that looks cute and works, but the compromises are not worth it (statement order is not obvious, if you make a mistake and two cases are true then do you know which wins, it could easily deoptimise the JIT compiler because it is doing something uncommon, I would worry how debuggers and code compressors would handle more complex cases, and understandability is poor for new devs IMHO).

Interesting at first glance, but what is the performance of this? It looks like all cases would have to be evaluated before picking one, so even slower than an if-else-if.

Isn't it going to short-circuit with the return of the first truthy statement?

The expression immediately to the right of each 'case' keyword is evaluated before the resulting values are compared to true.

If that's the case, then wouldn't both "asdf" and "qwer" be printed to the console when executing the following code?

  function test() {
      switch (true) {
          case console.log('asdf') === undefined: return 1;
          case console.log('qwer') === undefined: return 2;
      }
  }
  test();

Hmm, I wrote some similar test code before writing my comment, but only included one 'case'. Indeed, you're right, they're evaluated only as needed.

That entire example in general reads more like a cautionary tale about coding yourself into overly-specific clunk in the service of staying 'vanilla'. The 'type' of things being sorted is hardcoded into the html of the table and the actual js code. The comparator function has specific logic just to handle ascending and descending sorts of that that particular table. This one 'simple' example is already more convoluted and brittle than it would be even if you 'reinvented' your own framework-like thing.

Reply on news.ycombinator.com