Both of these filter functions return numbers, not booleans. Similarly, you could strip empty strings out of an array by just returning the string in the filter function:
hey yes you can but it's not totally clear for every dev that will read your code! I prefer the option of making a good return about a condition ! I edited the post to add your comment thanks
If we want to make the code totally clear for every dev, then we need to write for the lowest common denominator of understanding... which is obviously a terrible idea since no developer will ever get any better, or understand how JS actually works
Coerce to boolean is a bad practice and you are not a better programmer because you use one less line of code, also developers that write clear code are not child
I very much did not say they were children. I said that by misleading them and falsely telling them they have to do something - you are treating them like a child - assuming they cannot understand the language feature and make the choice for themselves. You are denying them knowledge, to preserve the dogma of 'clean' code
I know the docs, I know js and I know coertion, I also know this kind of things lead to bugs and thats why we have lint rules and typescript.
If you want to filter strings and abuse coertion you will lost one valid result from this array [null, '', 'valid'], just because one smart developer didnt want to write some extra text
You should probably email Mozilla to get them to change their docs - they're condoning abuse!
Seriously though, there's nothing wrong with doing it if you understand the ramifications. Sure, you gave an example with a very particular situation where there might be an issue, but there are also times when you KNOW what data is going to be coming in, and can code appropriately.
The docs are fine because they reflect reality. But js has many parts that work in weird ways that should be avoid to write maintanible code and make life a little easier for the person that is working in your code after you
If we always encourage developers to avoid the quirks, and sweep them under the carpet pretending they don't exist - knowledge of JS over the years will get progressively worse (something that I've actually seen happening over years of interviewing candidates), and you're denying the developers the chance to be better developers through a more complete understanding of the language. That is a bad idea. Learn about the quirks - learn why they're good, learn why they're bad, learn how they can help you, use them to your advantage when you can.
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.
This isn't true. You can return anything you like - the value will be coerced to a boolean based upon its truthiness or falsiness. Examples:
Both of these filter functions return numbers, not booleans. Similarly, you could strip empty strings out of an array by just returning the string in the filter function:
This works because non-empty strings are truthy and empty strings are falsey
hey yes you can but it's not totally clear for every dev that will read your code! I prefer the option of making a good return about a condition ! I edited the post to add your comment thanks
If we want to make the code totally clear for every dev, then we need to write for the lowest common denominator of understanding... which is obviously a terrible idea since no developer will ever get any better, or understand how JS actually works
Coerce to boolean is a bad practice and you are not a better programmer because you use one less line of code, also developers that write clear code are not child
I very much did not say they were children. I said that by misleading them and falsely telling them they have to do something - you are treating them like a child - assuming they cannot understand the language feature and make the choice for themselves. You are denying them knowledge, to preserve the dogma of 'clean' code
From the MDN docs for
filter
:I know the docs, I know js and I know coertion, I also know this kind of things lead to bugs and thats why we have lint rules and typescript.
If you want to filter strings and abuse coertion you will lost one valid result from this array [null, '', 'valid'], just because one smart developer didnt want to write some extra text
You should probably email Mozilla to get them to change their docs - they're condoning abuse!
Seriously though, there's nothing wrong with doing it if you understand the ramifications. Sure, you gave an example with a very particular situation where there might be an issue, but there are also times when you KNOW what data is going to be coming in, and can code appropriately.
Appropriate code for appropriate situations
The docs are fine because they reflect reality. But js has many parts that work in weird ways that should be avoid to write maintanible code and make life a little easier for the person that is working in your code after you
If we always encourage developers to avoid the quirks, and sweep them under the carpet pretending they don't exist - knowledge of JS over the years will get progressively worse (something that I've actually seen happening over years of interviewing candidates), and you're denying the developers the chance to be better developers through a more complete understanding of the language. That is a bad idea. Learn about the quirks - learn why they're good, learn why they're bad, learn how they can help you, use them to your advantage when you can.