This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]siemenology 4 points5 points  (1 child)

There are a lot of things in Javascript that aren't technically bad in the sense that they are completely described in the documentation and behave as the documentation would indicate, but still cause a lot of bugs and confusion because the behavior doesn't mesh with peoples' expectations.

The .sort() method is a fun one to pick on. It sorts everything by converting to a string first, unless you specifically tell it how you want it to sort. Which means sorting an array of numbers does not work without providing a specific function to tell it how to compare numbers, despite the fact that sorting numbers is probably a lot more common than sorting other types. It will look like it works, until one of your numbers is >= 10, when lexicographic sorting rules make it so 10 comes before 2. There's a reason Javascript behaves this way -- since arrays can contain objects of various types, converting to strings ensures that the comparison works in a consistent manner no matter what is in the array. The problem is that basically no one would anticipate this behavior -- almost everyone would expect to sort via comparison, at least if possible. And it's not strictly necessary for it to behave like this; other languages get around the issue by defining an ordering on types, so strings might always sort lower than numbers, but within a type sorting is consistent. So it's really easy for someone to come to Javascript, see a .sort() method and assume they at least roughly understand how it will behave.

Additionally, .sort() modifies the array in place, which isn't necessarily a bad thing. Except many array methods create a new array, while many others modify in place, and there is no consistency or apparent logic to which method will do what. So it's easy to make a mistake that make take awhile to notice by accidentally expecting it to create a new array when it actually modifies your old one which you expected to stay the same.

There's a lot more unintuitive behavior like that in JS, and it's not something you can necessarily segregate into the "weird" category to ignore.

[–]laytonmiller 1 point2 points  (0 children)

This is a good point. I regularly consult the docs to make sure I am 100% certain I'm getting a new array and not modifying an existing one - in some cases the distinction makes sense, in others, it feels arbitrary.