The example for the "make more robust" brush puts the prefixed css properties at the end which is the opposite of what you should do...

"Make more readable" looks awful too, the correct output would've been something like:

    (a == null || b == null) ? NaN :
    a < b ? -1 :
    a > b ? 1 :
    a >= b ? 0 :
    NaN;

That’s not readable at all. Chaining ternary operators like that is much worse than the code the article shows.

Maybe it’s a stylistic choice, but there’s nothing wrong with a sequence of “else ifs” as long as you don’t go deeper (like in the example)

Chained ifs add a whole lot of visual noise, aren't guaranteed to be total, and introduce the temptation to add more logic into the cases.

That said, I do wish more languages had copied Haskell's guard syntax for this kind of chain... For reference, that looks like:

    cmp x y | (x == Nothing || y == Nothing) = NaN -- (assuming x and y are Maybe, but this would typically be non-idiomatic)
            | x < y = -1
            | x > y = 1
            | x >= y = 0 -- inert bug copied from original, "should" be == instead
            | otherwise = NaN

I too always find myself wanting features from functional languages, I haven't done much Haskell but love the syntax for pattern matching in Elixir with guards, plus the pipe operator.

This would be a perfect case for a match expression, which, surprisingly, PHP now supports:

  return match(true) {
    $a == null && $b == null => null,
    $a < $b => -1,
    $a > $b => 1,
    $a == $b => 0,
    default => null;
  }

I’m surprised this feature isn’t prevalent in modern languages. It makes the code so concise and easy to understand, it’s marvellous.

What interests me here is that both your version and the else if version perpetuate the error in the original code which is the case where a is greater than b, which is handled once by a greater than comparison, and then again by a greater than or equal to comparison, which is clearly redundant. Neither CoPilot, nor you, nor the article author I presume caught this error in the flow control. Catching errors like these adds more value then making it more readable, although making it more readable certainly did expose the error more clearly to me.

I did notice it but wanted to keep the AST identical. But yes, it would have been worth pointing out, heh.

Actually it is not redundant as >= do numerical comparsion (so convert a and b to number) while == do not do that. So it has different result on objects.

You learn something new every day! I have written JavaScript off and on for years and did not encounter that.

I've used a few of these but to be honest they're worse than ChatGPT, and they're almost nigh useless. I'm not sure what model Microsoft is using because they own half of OpenAI now, they should integrate the ChatGPT model instead of the older Codex one, it seems.

I've been experimenting with this kind of thing lately, but what I've found more useful is the "edit" mode in the openapi playground. You paste your existing code in there, give some instruction, then submit, and it seems to do pretty well. I'm hoping that the next generation of Copilot will be able to make use of this, as sort of "dynamic brushes"