JavaScript the Good Parts Understanding Good Programming Style

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Douglas Crockford: But the biggest problem was I said, that hardly ever happens. That system one, system one can't quantify. System one thinks that not very often is the same as never. System one waits most greater than all. It's just bad at math and always relying on system one, not on any kind of statistics or real model, for what went wrong there.

[00:00:31] So yeah, that hardly ever happens means it happens, doesn't happen a lot but it does happen. And if you're trying to be perfect, you can't allow for it to ever happen, right? So start realizing that there's some features that I simply want to avoid all the time because they're slightly more likely to produce errors.

[00:00:54] And if we're gonna avoid using those forms then I'm gonna be spending less time in the abyss. So a good style can help produce better programs. Style shouldn't be about personal preference or self expression or things that you're used to, it should be about what will effectively reduce my error rate?

[00:01:14] Not to help me reduce my keyboarding, because it turns out keyboarding is in the noise, that's not where we spend our time, we spend our time debugging. So if I can save time in debugging by typing in a little bit more code that turns out to be a hugely good trade of.

[00:01:31] So we can find some clues about this literary style. The Romans wrote Latin all in upper case with no word breaks or punctuation and that worked pretty well for them for a long time. Although there's some ambiguities, for example, the third line could be read now wor DB reaks.

[00:01:51] I don't know what that means.
>> Class: [LAUGH]
>> Douglas Crockford: But from my eye, this is harder to copy. Just cuz there's less redundancy in it, it's a little bit harder. But the Romans were able to deal with this until Constantine established Christianity as the state religion of the Roman Empire.

[00:02:12] And at that point it became necessary to make copies of all these documents, and distribute them all over the world. But what they found was, they did not have the originals for any of these documents. And every copy they had were different, none of the copies agreed. So every time this stuff was copied, errors were introduced.

[00:02:33] And this was a problem for an institution that was claiming its authority based on the word and no body was sure exactly what the word was. So Medieval copyist introduced lowercase, word breaks, and punctuation. And this innovations helped them to reduce the error rate. Having this in the manuscript made it easier for them to copy the text without introducing new errors, and that turned out to be hugely beneficial.

[00:03:00] And one unexpected benefit of this was it also made the documents easier to read. So when Gutenberg started printing, he copied these conventions because they work, and we are still using them. We have centuries and centuries of experience using these literary patterns, and they are in everything that we publish now.

[00:03:21] We have all been taught at least since kindergarten and probably earlier to recognize these things. So we know to put a space after comma and not before a comma. That's just good style, it's something we've all been reading all of our lives. So if you're a novelist and you're trained to demonstrate your creative power.

[00:03:43] You don't do that by putting your periods at the beginning of your sentences, instead of at the end. No critics gonna say, wow, what masterful use of punctuation. No, as a novelist, you're gonna be demonstrating your creativity by the things that you're describing and the technique that you use to describe them.

[00:04:05] You'll at the same time slavish conform to the rules of style, because that's part of the deep structure of what you're communicating, that that's not what you play with.
>> Douglas Crockford: So good use of style can help reduce the occurrence of errors. We have centuries of evidence that support this.

[00:04:31] So one excellent manual on style is The Elements of Style by William Strunk. He self-published this about 100 years ago. Some of his advice is a little dated now because English has continued to evolved since then, but most of its advice is still really good. And a number of computer scientists have recognized that and witness style guides based on Strunk's guide, applying his rules to English or to programming languages, and it's really effective.

[00:05:03] So programs must communicate clearly to people. There are some who think that you just have to get it pass to the compiler and if the compiler gets it then that's all you need to do, it's done. But that's not true, if the program is ever gonna have to run more than once then it needs to be written so that someone knows how to modify it in order to improve it, or at least understand what it does.

[00:05:30] And it's not good enough to say, well, somebody should be able to figure it out, you don't wanna get the punctuation wrong. Assuming that someone's gonna have to work through it, the same way that novelist shouldn't. You know what? The spellings and bad styles to be in your work, even though people could figure it out, that's not where you want them spending their mental cycles.

[00:05:50] You want them investing all of their mental cycles on understanding the deep stuff, the important stuff. So we should use elements of good composition where applicable. So we should put the space after the comma, not in front of the comma. We should not depart from the rules of style that we've had for centuries, unless we have solid data which shows there's a clear benefit in this deviation.

[00:06:15] If there's not that evidence then we should stick to this stuff because it's what most of us know and it does help us to effectively communicate. Now, programs have to be more rigorous than writing has to be. So we may need other style rules to help us disambiguate.

[00:06:36] For example, we use pairings for a lot of things. One of them to create and invoke functions. So we have a convention that you don't have a space between a function name and a paren, and that it helps us to distinguish all of the other cases. For example, there should be a space here after the return.

[00:07:01] Now, in some languages, return might be a function, in which case that line is perfect the way it is. But in JavaScript, it's not return as a statement not a function and so we should write it with a space there to make it easier for the person who's reading his program to understand what is the role of that statement.

[00:07:21] One of the good part in JavaScript is the immediately invocable function expression. This is the thing which allows us to have modularity and JavaScript because we can take advantage of function scope to keep things out of the global scope, and that turns out to be hugely beneficial. We'll talk a lot more about that later.

[00:07:40] Unfortunately, JavaScript has some tactic ambiguity if function appears in statement position, then it's a different kind of thing and we cannot immediately invoke it. So someone discovered that if you wrap the function in parentheses, then it's no longer in a statement position and then we can invoke it, and so you see a lot of code like that.

[00:08:03] But I think this misses an opportunity, while this is sufficient to get it past the compiler, I want to give a little bit more information to the reader. And I can do that by slightly changing the parentheses. Because I've got the invoking parens out there, just hanging out there like a pair of dog balls, right?

[00:08:23]
>> Class: [LAUGH]
>> Douglas Crockford: And what's important here is the entire thing. So I wanna wrap the entire invocation expression in parens. As a cue to the reader that what's important here is not the function, it's the invocation of the function. And so I want the parens to be inclusive of the whole thing.

[00:08:46] Again, the compiler doesn't require this, but I think good style does. Now, I told you about semicolon insertion. Here's another of the things that it'll get wrong. You would hope that there'd be a semicolon inserted there but there isn't, so this will fail. Instead of assigning y to x, you will assign y invoked as a function passing the result of the other function as its argument, which is probably not what you intended.

[00:09:19] My advice is never rely on semicolon insertion, always put the semicolons in the right places. Now, in most cases, this doesn't happen, but again it sometimes does happen which means it happens. And so you need to adopt a programming style which helps defend you against these sorts of mishaps, it'll make you look smarter.

[00:09:48] Another innovation that JavaScript added, it was a good intention but it didn't work out right, was the with statement. So here we have this with statement in green and it will expand into one of these four statements. Now, can anybody guess which of those four it will become?

[00:10:10]
>> Class: Second one?
>> Douglas Crockford: It's a trick question, it could be any of them. There's no way to tell from reading the program which one it's going to be. In fact, every time that statement executes, it could potentially be a different one. So if we're trying to write programs which clearly communicate what they do, we can't do that if we're using forums which we cannot predict what they're going to do.

[00:10:35] So my advice is don't use the with statement, you simply don't need it. And by taking it out of your working set, there's a whole class of confusions which go away. Now, there's some people who have discovered a lot of very clever uses foo with the statement. And they say, well, I should be able to use it to do those very clever things because it's sometimes useful.

[00:11:00] But my argument is not that it isn't useful, I'm saying there's never a case where it is never confusing and confusion is the thing we want to avoid.