Having multiple return statements can make it harder to understand code. Especially in code with side effects, the typical reason to have multiple returns is because you’re trying to do something clever–that, or early-out error checking. In either case, having a sub-function that verifies arguments can be more testable and clearer. In some cases, multiple returns can be handy. Much has been written on this topic.
Using ternary operators can lead to ugly code. Judicious use for simple assignments (say, clamping) is fine and can improve readability, but all too often people try to get clever by nesting ternaries or by putting executable functions in the clauses. This is tacky.
Using objects of functions (read: function pointer tables, all that is old is new again, etc.) can be quite preferable to a switch statement. However, you have to have a way of falling back ala the switch default case–and the author is sharp enough to provide that here. What the author doesn’t do, though, is handle the case where using an object literal as they are will bring in more functions than they need–they should’ve started with an Object.create(null) or zeroed out __proto__ after declaring the map, since otherwise weird things will happen. Consider the case where message type is set to toSource or some other function that exists on the base JS Object class.
A few points:
Having multiple return statements can make it harder to understand code. Especially in code with side effects, the typical reason to have multiple returns is because you’re trying to do something clever–that, or early-out error checking. In either case, having a sub-function that verifies arguments can be more testable and clearer. In some cases, multiple returns can be handy. Much has been written on this topic.
Using ternary operators can lead to ugly code. Judicious use for simple assignments (say, clamping) is fine and can improve readability, but all too often people try to get clever by nesting ternaries or by putting executable functions in the clauses. This is tacky.
Using objects of functions (read: function pointer tables, all that is old is new again, etc.) can be quite preferable to a switch statement. However, you have to have a way of falling back ala the switch
defaultcase–and the author is sharp enough to provide that here. What the author doesn’t do, though, is handle the case where using an object literal as they are will bring in more functions than they need–they should’ve started with anObject.create(null)or zeroed out__proto__after declaring the map, since otherwise weird things will happen. Consider the case where message type is set totoSourceor some other function that exists on the base JSObjectclass.