Crazy and passionate Front-end Developer. In love with the details of app-dev. Always eager to bring ❤️ to the world in the shape of software and knowledge 😺
Location
Stuttgart, Germany
Education
14 years of autonomous learning of software architecture for web and smart home development
Everything which does not belong to the function should not be mutated.
I have experienced that some devs love to write huge functions that span multiple pages. Which is something that is not ok for me. It might be convenient to just add to an ever increasing scope to never juggle state from one function to another, but it quickly becomes opaque which variable is mutated at which point or re-used somewhere else along the pages of code. So the rule of "mutation is ok within the same function" depends on how absurdly you stretch the rules, or in that case the function.
If it is compact, then maybe. But most of the time I prefer a re-usable function that you can apply to a map instead of writing a for loop that collects some data.
FP has the promise of a declarative style that should make it more readable. Sometimes that is true, when you know what the words mean:
It needs some setup, but once you have the function assembled, you don't need as much boilerplate than with if and for statements EVERY TIME you use it. that is the entire point of FP. You can compact a lot of behavior into one function, give it a fitting name and re-use it as much as you want.
Ok, to be fair, we can apply at least the isOddNumber function within the if condition.
What bugs me the most, is that all these imperative statements (if, switch, for) always come with their own boilerplate. If you work on the result of getOddNumbers you have to do a for loop once more, which adds to the boilerplate.
I know why I do FP and I know why state mutation and statements are most oftenly not ideal to express your desired computation or behavior.
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
I would just answer - it depends. We state our opinions, in contrary to you I see also problem in extending dictionary for such simple cases, in my experience creating so many one liner function can end in ton of functions which nobody will use because they just prefer to write them inline. The example which shows that is famous id function, I personally prefer to just use x => x than import id from magic utils, it is just too simple.
As having functions and composing them is a good thing, we need to take into consideration that more one liners mean also more jumping over the code. I was writing Elm for a while and I found myself in preferring using inline if expressions, or inline case of instead of constantly creating new function. As I loose eye contact with what is really going on, and having many functions force me to jump through them. And no, readable name not always is enough to say that we never want to see what is going on.
Also when I see this:
constfilterList=fn=>arr=>arr.filter(fn)
It is 🚩 for me, as this is nothing more like duplicating the already existing tools, such function in my opinion has no value, and even worst introduce smth which is additional in the codebase. So for me your first implementation:
is better, and probably I would even wrote that in that way, but this example is simplified and doesn't shows the whole picture.
I don't force anybody to use mutation, I am just saying that it is fine to mutate locally, it is fine to use "for" loops, nothing wrong with that. Of course if we just reimplement map or filter then we should think twice. But if function makes more than that, transformation for example needs reduce then reaching for loops is fully ok. I don't feel pain looking at statements, also "boilerplate" can happen with expressions, Elm is famous for having a lot of boilerplate, even though it has no statements at all.
And yes I prefer expressions over statements, but I in the same way I hate ternary expression and prefer if statement, as it is just more readable. Python has <expr1> if <conditional_expr> else <expr2> and this is awesome. But in JS, nah, ternary is really not nice.
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.
I have experienced that some devs love to write huge functions that span multiple pages. Which is something that is not ok for me. It might be convenient to just add to an ever increasing scope to never juggle state from one function to another, but it quickly becomes opaque which variable is mutated at which point or re-used somewhere else along the pages of code. So the rule of "mutation is ok within the same function" depends on how absurdly you stretch the rules, or in that case the function.
If it is compact, then maybe. But most of the time I prefer a re-usable function that you can apply to a
map
instead of writing a for loop that collects some data.FP has the promise of a declarative style that should make it more readable. Sometimes that is true, when you know what the words mean:
or better:
It needs some setup, but once you have the function assembled, you don't need as much boilerplate than with
if
andfor
statements EVERY TIME you use it. that is the entire point of FP. You can compact a lot of behavior into one function, give it a fitting name and re-use it as much as you want.vs
Ok, to be fair, we can apply at least the
isOddNumber
function within theif
condition.What bugs me the most, is that all these imperative statements (if, switch, for) always come with their own boilerplate. If you work on the result of
getOddNumbers
you have to do afor loop
once more, which adds to the boilerplate.I know why I do FP and I know why state mutation and statements are most oftenly not ideal to express your desired computation or behavior.
I would just answer - it depends. We state our opinions, in contrary to you I see also problem in extending dictionary for such simple cases, in my experience creating so many one liner function can end in ton of functions which nobody will use because they just prefer to write them inline. The example which shows that is famous
id
function, I personally prefer to just usex => x
than importid
from magic utils, it is just too simple.As having functions and composing them is a good thing, we need to take into consideration that more one liners mean also more jumping over the code. I was writing Elm for a while and I found myself in preferring using inline
if
expressions, or inlinecase of
instead of constantly creating new function. As I loose eye contact with what is really going on, and having many functions force me to jump through them. And no, readable name not always is enough to say that we never want to see what is going on.Also when I see this:
It is 🚩 for me, as this is nothing more like duplicating the already existing tools, such function in my opinion has no value, and even worst introduce smth which is additional in the codebase. So for me your first implementation:
is better, and probably I would even wrote that in that way, but this example is simplified and doesn't shows the whole picture.
I don't force anybody to use mutation, I am just saying that it is fine to mutate locally, it is fine to use "for" loops, nothing wrong with that. Of course if we just reimplement
map
orfilter
then we should think twice. But if function makes more than that, transformation for example needsreduce
then reaching for loops is fully ok. I don't feel pain looking at statements, also "boilerplate" can happen with expressions, Elm is famous for having a lot of boilerplate, even though it has no statements at all.And yes I prefer expressions over statements, but I in the same way I hate ternary expression and prefer if statement, as it is just more readable. Python has
<expr1> if <conditional_expr> else <expr2>
and this is awesome. But in JS, nah, ternary is really not nice.