But is that really what you're looking for? I see that idiom and I think, "Ok, this is a comparator" and I move on. If I suspect a _bug_ in the comparator, then I'll look at it more carefully, but the context is about writing code whose intent is clear, not writing code that can be scanned for bugs easily - which would be a tall to impossible order anyway and isn't made any easier by sprawling your code across 10 lines where one will do.
If I see it "on the wild" (as part of a bigger function), however, my train of thought goes "Wait, why is this piece of code here instead of a function call called `comp`? Is this a comparator or is this something else? Ok geez time to do the javascript eye dancing thing. You know what? I'm just not going to approve this and demand that this piece of code is at least given a proper name and put somewhere. Possibly with unit tests"
Now consider this:
Or: Or: Are all these equivalent?Figuring that out is much more difficult than their 8-line counterpart, at least for me. My eyes have to keep jumping from left to right in order to do the checks, like they would do in a piece of uglyfied javascript.
That said, context is everything: if your one-liner was the single line in a function called `comp` with `a` and `b` as parameters, I would not comment on it in a code review.
However, if this line was part of a bigger function, and if instead of `a` and `b` we had `someLongVariableName` and `someOtherVariableName` I would not approve the pull request until this "oneliner" was changed into something else (possibly a call to the `comp` function).