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.
Replacing conditions by creating additional list structure and pushing items to it 🤔. I would say you are introduction here quite an anti-pattern, and it is visible for me on the first sight.
If you have such many or and and in some point, then the mistake was done earlier, your data model probably is wrongly made, you have too many data relations. The fix is to rethink how you store the data, and putting things into array is not any better.
There is a good use case for arrays instead of raw conditions though. If you have data which represent some variants, lets say something can be in shapeA, shapeB or shapeC then I would consider using array.some in that case. Lets see an example:
// role is a variant with few possible valuesif(role==='Admin'||role==='Moderator'||role==='SuperUser'){// do smth}// with array some we avoid repetitionif(['Admin','Moderator','SuperUser'].some(allowedRole=>allowedRole===role)){// do smth}// we can be more readable(subjective) by having isEqual functionconstisEqual=a=>b=>a===bif(['Admin','Moderator','SuperUser'].some(isEqual(role))){// do smth}
But if conditions are about different things, so we check different variables then I would say using array for that has no benefit for standard conditions, and even I would not recommend such approach.
I think we'll agree to disagree on the usage of arrays. For example, you are using some similar to how I describe where we check an array to see if the condition matches, albeit I state to place the results of conditionals into the array.
As for your isEqual function. That does not look friendly and any junior Dev coming along afterwards will be confused very easily.
The reasoning behind using the array for conditionals stems from situations where we aren't in control of the data model, and yes that can happen, due to time restrictions and due to working on legacy codebases or codebases that have had a lot of employees come and go with little documentation, where product tack new features on without sparing time to handle technical debt.
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.
The thing is that it doesn't hep in any way in terms of not controlling the data model, you have trouble if u do that by array or not. My examples of using .some show what I am able to accept in the code, but this examples also do not make any difference in terms of the code quality.
There is no, even single reason to change multi-conditions into multi-array of conditions. I disagree hard here because you have "Clean JavaScript" article title. This is not more clean, but alternative way of doing conditions. If I would see such in the code my first question would be - "Why?". And the only answer I see is - "Because I can"
PS. in terms of isEqual I agree, it is subjective, as point-free not always makes the code better.
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.
Replacing conditions by creating additional list structure and pushing items to it 🤔. I would say you are introduction here quite an anti-pattern, and it is visible for me on the first sight.
If you have such many
orandandin some point, then the mistake was done earlier, your data model probably is wrongly made, you have too many data relations. The fix is to rethink how you store the data, and putting things into array is not any better.There is a good use case for arrays instead of raw conditions though. If you have data which represent some variants, lets say something can be in shapeA, shapeB or shapeC then I would consider using array.some in that case. Lets see an example:
But if conditions are about different things, so we check different variables then I would say using array for that has no benefit for standard conditions, and even I would not recommend such approach.
Few thoughts about modeling the data:
I think we'll agree to disagree on the usage of arrays. For example, you are using
somesimilar to how I describe where we check an array to see if the condition matches, albeit I state to place the results of conditionals into the array.As for your
isEqualfunction. That does not look friendly and any junior Dev coming along afterwards will be confused very easily.The reasoning behind using the array for conditionals stems from situations where we aren't in control of the data model, and yes that can happen, due to time restrictions and due to working on legacy codebases or codebases that have had a lot of employees come and go with little documentation, where product tack new features on without sparing time to handle technical debt.
The thing is that it doesn't hep in any way in terms of not controlling the data model, you have trouble if u do that by array or not. My examples of using
.someshow what I am able to accept in the code, but this examples also do not make any difference in terms of the code quality.There is no, even single reason to change multi-conditions into multi-array of conditions. I disagree hard here because you have "Clean JavaScript" article title. This is not more clean, but alternative way of doing conditions. If I would see such in the code my first question would be - "Why?". And the only answer I see is - "Because I can"
PS. in terms of
isEqualI agree, it is subjective, as point-free not always makes the code better.