I am aware of the forms you demonstrated. Rest assured that I chose the naming and structure very intentionally. I avoid point-free notation in most cases. Hidden parameters do not tend to help readability. Spelling out the parameter isn't as concise, but it is far more clear. Especially when the reader might not be as familiar with FP.
It depends on your view on it. If you name the parameter, your view is "I will fold update over the list". Without the parameter your view is "runChallenge is a fold with update and some initial value". In my opinion this focuses on the algorithm and not the data making in easier to understand. A greater percentage of the code is thr actual algorithm as opposed to unnecessary stuff
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There is no need to name
inputList
.Thanks for your comment.
I am aware of the forms you demonstrated. Rest assured that I chose the naming and structure very intentionally. I avoid point-free notation in most cases. Hidden parameters do not tend to help readability. Spelling out the parameter isn't as concise, but it is far more clear. Especially when the reader might not be as familiar with FP.
It depends on your view on it. If you name the parameter, your view is "I will fold update over the list". Without the parameter your view is "runChallenge is a fold with update and some initial value". In my opinion this focuses on the algorithm and not the data making in easier to understand. A greater percentage of the code is thr actual algorithm as opposed to unnecessary stuff