Avoiding Number is considerably better for performance:
// for true/falseconstsubscribedUsersFirst=users.sort((a,b)=>+b.subscribed-+a.subscribed)// for any truthy/falsy (avoiding issues with undefined, bigint etc.)constsubscribedUsersFirst=users.sort((a,b)=>+!!b.subscribed-+!!a.subscribed)
Even if it's 30% faster, it won't matter in the end.
Why? because you won't use +x or Number(x) with 1 million operations in a second. You'll use it 99% of the time less than 3 times in a row. 30% is worthless here.
But using Number(x) makes it very easy to understand the intention of the code.
Using +x will be missed by a lot of devs and will only cause trouble.
Readability over pretty much anything, except when you absolutely need the performance, which is very rare. And if you disagree with this, then let's just agree to disagree...
Agree with this. Number is much more noticeable at-a-glance in the source code, whereas any minor improvement in perf doesn't make any practical difference and could easily be erased or reversed by future engine optimizations in any case.
Small correction to my original comment, though — it turns out that since the introduction of the bigint data type, +x and Number(x) are no longer semantically identical: Number(1n) gives 1, whereas +1n throws an error, because bigints can only be explicitly converted to numbers, not coerced. IMO, this is another argument in favor of Number(x), as it consistently works for all data types of x, without throwing (unless you do something crazy like x = { valueOf() { throw '' } }).
with reduce, there are few bits that are just not easy to understand:
that initial value is {}, it's passed as 2nd reduce argument, but it's just not easy to see it
the way you return value for reduce function (a, b) => (..., a) - it's very hard to understand here that the return value of this function is 'a'
it's hard to understand what is what when variable names are 'a' and 'b', at very least your suggestion could be improved by renaming a -> key and b -> occurrencesCount
Subjective is lazy excuse. UX is is subjective but we figure out what UX is better than other by trying to understand what approach works best for most of people. Unfortunately when it comes to readability - it's too often - that the most senior developer on team often will decide what's the most readable for him and reject all opinions as "subjective" and move forward in fashion of being "pragmatic" - this approach may be fine with other type of decisions for example having more experience tends to help making architectural decisions. However when it comes to readability - experience may be working the opposite way resulting in poorer choices. The more more time we spent looking in weird code the more readable it becomes to us. As experienced engineers we should be very aware of our bias towards making decisions that result in very steep learning curves.
My self as someone who had spent a lot of painful time reading through code parsing reduce that I can't immediately understand (despite coding for 15+ years) and as someone who had to countless time to ask to improve naming in reduce statement (often encountering "sorry I was lazy" excuses), and as someone who countless number of times had to explain to more junior developers how reduce works, I conclude that reduce is fairly poor practice in majority of cases.
Reduce could been little better if initial value was first argument - as opposed to last. The last value is just hard to notice, and logically makes no sense (it's initial yet comes later).
Subjective does not mean that there isn't approach that overall is better for the majority. Too often people reject arguments as "subjective" simply because it doesn't happen to follow their personal biases, likes/dislikes.
There is a lot of very objective arugment that I gave to you why reduce is bad (in this case). Yet the only thing you can do is reply that "it's subjective".
How can we more objectively approach this issue? If you would attempt to lose your biases we could do it. Basically I have stated my problems with 'reduce()' - what makes it bad. Even if you don't think (subjectively) that it's bad for you, the very fact that it's bad to me, already is a concern that we should attempt to solve. I have proposed solution how we can address the readability issues that I had. Now follow up is, for you to express, if you have readability issue with the approach that I suggested? If you have - we can try to see if I can propose something that works for both. But you don't say it. Instead you quit early from engaging in search for best approach and religiously stick to what you think is subjective and not worth discussing - remaining stuck with your personal favorite approach even if it's not the best approach for both or the whole community.
I'm not rejecting them, merely pointing out that they're purely subjective. You didn't raise a single objective argument - 'not easy to see', 'very hard to understand', and 'hard to understand' couldn't be more subjective.
There are downsides to rigidly promoting readability and 'clean' code above everything else. I brought these up in a previous post:
You say it's subjective. But I cannot agree with this. This comes from my personal experience of teaching others, and reading code and I have 15 years of experience in that. But if you are not convinced with my experience - that is fine. It is possible to setup experiment that could confirm or deny the premise that I make. Experiment could look like so: we take 200 random developers. We split them in half. We present them with a piece of code. We ask them a comprehension question, that we ask to answer as fast as is possible. Alternatively we can ask a question to modify the code to do something slightly else - this also would test not only how easy it is to comprehend the code but also how easy it is to change it which is also important. We compare the results of 2 groups. And we have objective answer.
The answer will not be subjective. It will be objective result (time it takes to get to correct answer). I'm not asking a question "chose your favorite". I would be asking "what is result of the code" and I'll be measuring the time it takes to get to correct answer. Some developers are smarter than others but on average one group will prevail over the other. Naturally the code that is easier to understand will produce faster results. Alternative question can be set to modify code to do something else. Again we can measure time it takes for each group to get to modified code - the group that gets it faster is objective winner. And even better approach - that truly will make the biggest difference in two approaches - could be to throw in a subtle bug - and ask developer to find and fix the bug. While in case of comprehension developers may often make a confidence guess based on looks - when it comes to subtle bugs - you only get to fix them when you truly parsed and perfectly understood every comma in code.
Totally correct, the results of your poll would be objective - a mere accounting of the results.
However, none of this alters the fact that readability and understandability in themselves are subjective, which is the point you seem to take issue with.
It's not subjective. It has easily measurable effects. Easier to read code is faster to spot bugs, faster to fix bugs, faster to teach unfamiliar developer who's just starting their career. It starts from a discussion on what is hard to understand (the very points I mentioned). And if you don't agree with my complains then please throw a randomized trial and prove it to me that my problems are only in my head and that other people don't have the kind of issues that I encounter when reading your poorly written code.
Again, I never disagreed with you. I merely pointed out that the properties of readability and understandability are subjective, which - by definition - they are.
I find it more interesting, educational, and stimulating to fix bugs that are challenging - rather than mundane stupid mistakes. It does nothing but sharpen your skills.
If you aren't enjoying the work you do and the code you write - why are you a programmer? The thrill of solving puzzles and gaining understanding is what drew me to writing code, and I dread the day that it ceases to be like that.
There's beauty in code, elegance in syntax, and art in converting your thought processes into functioning programs. I wish all developers could experience it like this.
I guess we can all agree that nobody likes to waste time on mundane mistakes. Question is what causes mundane mistakes and how to avoid them? And how can we make sure that mistakes are as easy to spot and fix as possible? The way I see it is that some of the ideas that you are trying to promote in fact is often a source of mundane mistakes that are difficult to detect yet you're keen to brush it off as simply being subjective.
Regarding beauty and subjectivity. Yes beauty of code is subjective. But it can be quantified. Subjectivity and beauty is merely a shortcut. By practicing one or another approach we can train our brains in what is beautiful and what's not so that we can more quickly judge what's better what's not without getting too much in depth into details of why something is better or worse - getting into details every time would be wasting a lot of our time. Yet going into details and turning subjective into objective very often is possible with more efforts put into reasoning, argumentation, thought experiments and real experiments.
I can tell you that the code you wrote is ugly and more beautiful would be this and that. You might agree with that and we'd save a lot of time. On other hand if you don't agree that doesn't necessary mean that there is no objectively better or worse approach here. We can get deeper into conversation and maybe we'd find quantifiable ways to judge which approach is better.
To me the approach that is the most easy to read and understand and requires lowest learning curve is the best the most beautiful - that's my brain shortcut that I often apply. And I cannot buy idea that introducing unnecessary complexity as a useful tool of gatekeeping less capable individuals is a beneficial practice (I got that you had this idea on your take on clean code). While gatekeeping using complexity can indeed work and I've seen projects getting away with it I just don't think it's the best we can do.
Unique Array of Objects
JSON.stringifywill give different strings for{ a: 1, b: 2 }and{ b: 2, a: 1 }- are you saying these 2 objects are 'different'?Split string by different chars
Using regex as it is intended is not a 'hack'.
Occurrence Counting
Reducing would seem a much better option here:
Constrain a number
Can be simplified:
Sort by Truthy/Falsy value
Avoiding
Numberis considerably better for performance:Wow, thank you for these suggestions! Mind if I link to your comment from the post?
Sure, no problem!
I'm extremely sceptical about this, as any JS engine worth its salt should be able to figure out that
+xhas identical semantics toNumber(x).JSBench confirms no noticeable difference (Chrome 110 on Windows 11) jsbench.me/c9le9hworr/1
I tried perf.link - was faster every time (Firefox and Chrome, Linux and Win11) - up to 30% faster in fact
Even if it's 30% faster, it won't matter in the end.
Why? because you won't use
+xorNumber(x)with 1 million operations in a second. You'll use it 99% of the time less than 3 times in a row. 30% is worthless here.But using
Number(x)makes it very easy to understand the intention of the code.Using
+xwill be missed by a lot of devs and will only cause trouble.Readability over pretty much anything, except when you absolutely need the performance, which is very rare. And if you disagree with this, then let's just agree to disagree...
Agree with this.
Numberis much more noticeable at-a-glance in the source code, whereas any minor improvement in perf doesn't make any practical difference and could easily be erased or reversed by future engine optimizations in any case.Small correction to my original comment, though — it turns out that since the introduction of the bigint data type,
+xandNumber(x)are no longer semantically identical:Number(1n)gives1, whereas+1nthrows an error, because bigints can only be explicitly converted to numbers, not coerced. IMO, this is another argument in favor ofNumber(x), as it consistently works for all data types ofx, without throwing (unless you do something crazy likex = { valueOf() { throw '' } }).I'd argue that classic approach of occurrence counting is much easier to read than the reduce approach
with reduce, there are few bits that are just not easy to understand:
{}, it's passed as 2nd reduce argument, but it's just not easy to see it(a, b) => (..., a)- it's very hard to understand here that the return value of this function is 'a'a -> keyandb -> occurrencesCountYeah, I was lazy with the argument names. Readability and understandability are purely subjective though
Subjective is lazy excuse. UX is is subjective but we figure out what UX is better than other by trying to understand what approach works best for most of people. Unfortunately when it comes to readability - it's too often - that the most senior developer on team often will decide what's the most readable for him and reject all opinions as "subjective" and move forward in fashion of being "pragmatic" - this approach may be fine with other type of decisions for example having more experience tends to help making architectural decisions. However when it comes to readability - experience may be working the opposite way resulting in poorer choices. The more more time we spent looking in weird code the more readable it becomes to us. As experienced engineers we should be very aware of our bias towards making decisions that result in very steep learning curves.
My self as someone who had spent a lot of painful time reading through code parsing reduce that I can't immediately understand (despite coding for 15+ years) and as someone who had to countless time to ask to improve naming in reduce statement (often encountering "sorry I was lazy" excuses), and as someone who countless number of times had to explain to more junior developers how reduce works, I conclude that reduce is fairly poor practice in majority of cases.
Reduce could been little better if initial value was first argument - as opposed to last. The last value is just hard to notice, and logically makes no sense (it's initial yet comes later).
How can readability and understandability NOT be subjective? They're purely dependent on the reader. That's subjective by definition
Subjective does not mean that there isn't approach that overall is better for the majority. Too often people reject arguments as "subjective" simply because it doesn't happen to follow their personal biases, likes/dislikes.
There is a lot of very objective arugment that I gave to you why reduce is bad (in this case). Yet the only thing you can do is reply that "it's subjective".
How can we more objectively approach this issue? If you would attempt to lose your biases we could do it. Basically I have stated my problems with 'reduce()' - what makes it bad. Even if you don't think (subjectively) that it's bad for you, the very fact that it's bad to me, already is a concern that we should attempt to solve. I have proposed solution how we can address the readability issues that I had. Now follow up is, for you to express, if you have readability issue with the approach that I suggested? If you have - we can try to see if I can propose something that works for both. But you don't say it. Instead you quit early from engaging in search for best approach and religiously stick to what you think is subjective and not worth discussing - remaining stuck with your personal favorite approach even if it's not the best approach for both or the whole community.
I'm not rejecting them, merely pointing out that they're purely subjective. You didn't raise a single objective argument - 'not easy to see', 'very hard to understand', and 'hard to understand' couldn't be more subjective.
There are downsides to rigidly promoting readability and 'clean' code above everything else. I brought these up in a previous post:
Preaching 'Clean Code' is Lowering the Quality of Developers
Jon Randy 🎖️ ・ Jun 25 '22 ・ 3 min read
You say it's subjective. But I cannot agree with this. This comes from my personal experience of teaching others, and reading code and I have 15 years of experience in that. But if you are not convinced with my experience - that is fine. It is possible to setup experiment that could confirm or deny the premise that I make. Experiment could look like so: we take 200 random developers. We split them in half. We present them with a piece of code. We ask them a comprehension question, that we ask to answer as fast as is possible. Alternatively we can ask a question to modify the code to do something slightly else - this also would test not only how easy it is to comprehend the code but also how easy it is to change it which is also important. We compare the results of 2 groups. And we have objective answer.
...based on the subjective opinions of 200 developers. The fact remains that readability and understandability are ultimately subjective.
My opinions are also drawn from long experience. I've been programming for 39 years, and doing it professionally for around 27.
The answer will not be subjective. It will be objective result (time it takes to get to correct answer). I'm not asking a question "chose your favorite". I would be asking "what is result of the code" and I'll be measuring the time it takes to get to correct answer. Some developers are smarter than others but on average one group will prevail over the other. Naturally the code that is easier to understand will produce faster results. Alternative question can be set to modify code to do something else. Again we can measure time it takes for each group to get to modified code - the group that gets it faster is objective winner. And even better approach - that truly will make the biggest difference in two approaches - could be to throw in a subtle bug - and ask developer to find and fix the bug. While in case of comprehension developers may often make a confidence guess based on looks - when it comes to subtle bugs - you only get to fix them when you truly parsed and perfectly understood every comma in code.
Totally correct, the results of your poll would be objective - a mere accounting of the results.
However, none of this alters the fact that readability and understandability in themselves are subjective, which is the point you seem to take issue with.
It's not subjective. It has easily measurable effects. Easier to read code is faster to spot bugs, faster to fix bugs, faster to teach unfamiliar developer who's just starting their career. It starts from a discussion on what is hard to understand (the very points I mentioned). And if you don't agree with my complains then please throw a randomized trial and prove it to me that my problems are only in my head and that other people don't have the kind of issues that I encounter when reading your poorly written code.
Again, I never disagreed with you. I merely pointed out that the properties of readability and understandability are subjective, which - by definition - they are.
I can agree that reduce does get a little bit hard to read, but one-liners or single array iteration functions are super fun to use.
We often endup spending more time fixing bugs than writing code. How fun is it to fix bugs in code that someone found fun to write?
I find it more interesting, educational, and stimulating to fix bugs that are challenging - rather than mundane stupid mistakes. It does nothing but sharpen your skills.
If you aren't enjoying the work you do and the code you write - why are you a programmer? The thrill of solving puzzles and gaining understanding is what drew me to writing code, and I dread the day that it ceases to be like that.
There's beauty in code, elegance in syntax, and art in converting your thought processes into functioning programs. I wish all developers could experience it like this.
I guess we can all agree that nobody likes to waste time on mundane mistakes. Question is what causes mundane mistakes and how to avoid them? And how can we make sure that mistakes are as easy to spot and fix as possible? The way I see it is that some of the ideas that you are trying to promote in fact is often a source of mundane mistakes that are difficult to detect yet you're keen to brush it off as simply being subjective.
Regarding beauty and subjectivity. Yes beauty of code is subjective. But it can be quantified. Subjectivity and beauty is merely a shortcut. By practicing one or another approach we can train our brains in what is beautiful and what's not so that we can more quickly judge what's better what's not without getting too much in depth into details of why something is better or worse - getting into details every time would be wasting a lot of our time. Yet going into details and turning subjective into objective very often is possible with more efforts put into reasoning, argumentation, thought experiments and real experiments.
I can tell you that the code you wrote is ugly and more beautiful would be this and that. You might agree with that and we'd save a lot of time. On other hand if you don't agree that doesn't necessary mean that there is no objectively better or worse approach here. We can get deeper into conversation and maybe we'd find quantifiable ways to judge which approach is better.
To me the approach that is the most easy to read and understand and requires lowest learning curve is the best the most beautiful - that's my brain shortcut that I often apply. And I cannot buy idea that introducing unnecessary complexity as a useful tool of gatekeeping less capable individuals is a beneficial practice (I got that you had this idea on your take on clean code). While gatekeeping using complexity can indeed work and I've seen projects getting away with it I just don't think it's the best we can do.
Seems like you misunderstood my take on clean code too
Just gonna go ahead and throw this Jake Archibald Twitter thread into the mix: twitter.com/jaffathecake/status/12...
As a fellow once-frequent, now-seldom user of
reduce, I tend to agree with him.