Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
How should one compare the letter counting objects for the fastest time complexity? JSON.stringify doesn't work here because the properties are not ordered. { a: 2, b: 2 } will not equal to { b: 2, a: 2 }.
Same here but to honor the DRI metric I decided to abstract the funtion that sorts the string.
It is used twice in the code.
indeed 'almost everyone', it's very readable and easily understood
we use predefined methods, of course we can define faster sort. eg. using .replace(/./g,...)
This comment is hidden because it contains spoiler information about the solution
TBH, type coercion in JS is terrible both as a concept and as an implementation. As many other things in JS. But that doesn't mean anyone should "prefer Python instead".
Fun fact - almost everyone use split/sort approach, which in fact is very slow.
This comment is hidden because it contains spoiler information about the solution
The simple rule is that primitives are passed-by-value and complex (objects) are passed-by-reference. Types that act like primitives (String, Number, Boolean, etc...) when created using the new keyword are complex objects and will be passed-by-reference but many of the operations that can be done on those will coerce the result to a primitive.
I like your approach.
Among those potential bugs are possibilites like starting to actually love JavaScript.
And in particural the == operator because it saves so much typing when you actually learn the simple coercion rules.
;)
There're a lot of potential bugs that can emerge from using JavaScript. I suggest that everyone use Python instead. Always.
You should always be wary of someone who tells you to "always" do something. They're usually wrong.
Great solution!
Just a minor objection as just a few hours ago I watched Douglas Crockford talking about potential bugs that can emerge from using ==. He suggests using === instead. Always.
Sample tests should be added.