Check out a free preview of the full Getting Started with JavaScript, v2 course

The "Coercion Best Practices" Lesson is part of the full, Getting Started with JavaScript, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Kyle argues for making types and type conversions obvious, and frames the quality of a program related to types in terms of the reader of the code.

Preview
Close

Transcript from the "Coercion Best Practices" Lesson

[00:00:00]
>> Kyle Simpson: The point I wanna get across is that a quality JavaScript program always embraces these types of conversion. And we have to make sure that the types that we're involving in those operations are as clear as possible. It's not the case that having JavaScript do these conversions is buggy.

[00:00:17]
It is the case that if we are not clear on what the types are, then we can accidentally miss those corner cases that we're talking about. So a quality JavaScript program makes those things very obvious. Make it obvious that if you're doing some math, everything's already a number.

[00:00:32]
And if its not already a number, make sure it's obvious that you're turning it into a number. If you make your types obvious in your programs, the vast majority of all those weird quirky corner cases that you've heard people moan and complain about go away. They really do go away as long as it is very clear.

[00:00:50]
I'm doing something numeric and both of these things are a number, then we really don't have a lot of corner cases to worry about
>> Kyle Simpson: Doug Crockford, many of you know that name, he's famous for a number of things, including the book that he wrote, JavaScript, The Good Parts.

[00:01:06]
And in JavaScript, The Good Parts, he has this statement. He says if a feature is sometimes useful and sometimes dangerous, and if there is a better option, then always use the better option. Now this is an oft-quoted idea. It's thrown around the JavaScript and even the greater programming communities a lot.

[00:01:23]
And it sounds very wise at the outset, but I am troubled by this statement. And I wanna point out why I'm troubled by it, because it uses terminology that is not particularly well agreed upon across the broader programming communities. So for example, what does he really mean by useful and dangerous?

[00:01:42]
If I asked you or you or you what useful and dangerous means, I'm gonna get three to five different answers. I'm gonna get a lot of different answers to precisely what does useful and dangerous mean. And so if we don't have a clear definition for those words, then we can't really make much action out of this wisdom.

[00:02:02]
And in particular, the one that bothers me the most is, how do we even define what better option means? Is there a better option? How can you definitely say there is? By the way, his quote is used in terms of saying, don't use all these coercion mechanisms in JavaScript because there's a better way.

[00:02:21]
But really, there isn't actually a better way. And I would claim that the better way ends up producing worse programs. Programs that are more cluttered, they're harder to communicate. And yes, you might avoid one particular set of problems, but you introduce a different set of problems, and then you blame that on some other part of JavaScript, instead of simply saying let's step back and ask what does useful mean?

[00:02:43]
What does dangerous mean and what does better mean? So to answer that question, I wanna give you a very brief alternate definition for those words. If we're gonna use this quote, I'm gonna give you a different alternate definition. First of all, I would say useful is when the reader is focused on what's important.

[00:03:00]
So if the reader of your code can see something and they are focused on the thing that they really should be focused on, then I'd call that useful. If the reader is focused on something and they really can't figure out what's gonna happen, I would call that dangerous.

[00:03:16]
So we shouldn't have stuff that's hard to figure out. You should avoid things that are hard to figure out. And most importantly, to determine whether something is better or not, I would say that when the reader understands the code better than before, then that code is better. That is the ultimate metric is that is it more understandable, is it more readable, then it's better.

[00:03:37]
Now you may disagree with those definitions, but I think at least putting a pin on some definition and saying this is what I mean by useful, this is what I mean by dangerous, and this is what I mean by better. At least we can have a more productive conversation about the decisions we should be making in our code.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now