5 ms·
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...
by teg4n_ 4y ago
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...
- Nullabillity 4y ago"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;
- mpeg 4y agoThat’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)
- Nullabillity 4y agoChained 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
- mpeg 4y agoI 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.
- 9dev 4y agoThis 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.
- drittich 4y agoWhat 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.
- Nullabillity 4y agoI did notice it but wanted to keep the AST identical. But yes, it would have been worth pointing out, heh.
- garaboncias2 4y agoActually 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.
- drittich 4y agoYou learn something new every day! I have written JavaScript off and on for years and did not encounter that.