Open breki opened 4 years ago
While a good point for the case you mentioned, there are many cases where composition creates better readable code, like:
// this
let yourName = fun() -> getInput() |> fun x sprintf "name: %s" x
// vs:
let yourName = getInput >> sprintf "name: %s"
And many variants of that. Perhaps the rule could be tailored for cases that involve operators. Though personally, I don't mind seeing (op)
in code.
BTW, your rewrite is not synonymous with the original. You wrote sin >> (~-)
, but that should probably be (~-) >> sin
, if it is to match fun x -> -sin x
(just saying in case it's an error in your original code, the example is otherwise clear ;).
My recommendation is to find criteria to reduce the recommendation of >> composition.
For example never for operators.
Perhaps some other cases too. See my talk "F# Code I Love" for exposition of some of this.
BTW, your rewrite is not synonymous with the original. You wrote
sin >> (~-)
, but that should probably be(~-) >> sin
, if it is to matchfun x -> -sin x
(just saying in case it's an error in your original code, the example is otherwise clear ;).
Yeah, sorry, it was suggested by someone on Twitter and I didn't really check it before posting it as an example here, my bad :-(. I agree about the usefulness of composition, it's just that I don't feel the code is more readable in this particular case of a unary operator being applied.
@abelbraaksma
BTW, your rewrite is not synonymous with the original. You wrote
sin >> (~-)
, but that should probably be(~-) >> sin
, if it is to matchfun x -> -sin x
No, yours isn't ;). First apply sin
, then negate. It's just that it makes no difference in the case of sine since sin -x = -sin x
Description
FSharpLint suggests I should replace lambda expression like
fun x -> -sin x
with composition, which makes a much less legible code (likesin >> ((*) -1.)
orsin >> (~-)
).Repro steps
Define a lambda like
Expected behavior
FSharpLint should accept the existing lambda expression as it is.