Programming Style

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

[00:00:03]
>> Douglas Crockford: The switch statement is another of Thompson's things. It was modeled after, or inspired by Tony Hoare's case statement, which was this brilliant idea that we will have several independent clauses, and we will pick one of them based on the value of an expression. Brilliant idea, but Thompson reinterprets it in the form of a computed GOTO, which is another thing that was in Fortran which we've since decided is a bad idea, except it survives in almost all modern languages in the form of the switch statement.

[00:00:40]
>> Douglas Crockford: And the hazard is the fallthrough hazard, that in any case, if you do not explicitly disrupt, it will automatically fall into the next case. And early on when I was developing JSLint, someone wrote to me and recommended that JSLint give warnings on this because it's really difficult to look at the code and observe that one case is falling through into another, because the syntax is designed to obscure that fact.

[00:01:10]
And I thought about it deeply, and I wrote back to him and I said, I can understand that hazard, but there's this wonderful elegance that you can get if you can cause one case to fall into the next one. And that's a valuable thing, and the error can happen, but it hardly ever happens.

[00:01:29]
And so given you've got this good thing that can happen versus this unlikely bad thing, I'm not gonna test for that, I'm not gonna give warnings on it. I think this is actually a good part of the language. The next day, the same guy wrote to me and said, I found a bug in JSLint.

[00:01:45]
So I said, okay, good, thank you. I open the debugger and it turns out, you know where this is going, right?
>> Speaker 2: Mm-hm.
>> Douglas Crockford: I had a case that was falling through. And in that moment, I achieved enlightenment cuz it turns out we spend most of our time making and fixing our own bugs.

[00:02:06]
We think, what I do today, I was power typing. I was typing. We spend most of our time saying, my god, what have I done? And then we find it, and we get this little rush of euphoria. I did that again. Boom, and we forget. And so we have all this lost time.

[00:02:21]
We forget about how much time we spend chasing bugs. And we fail to learn from our mistakes. But on this particular occasion, it was so humiliating, because I had just given a speech about how this was a good part and then I'm shown, by the same guy, a bug in my own code that was caused by that thing that I was defending.

[00:02:42]
And because it was so humiliating, I could not avoid learning the lesson, which was, if I never intentionally fall through, I can find the cases where I accidentally fall through. And that turns out to be much more valuable, and it caused me to re-examine my analysis, and it turned out I was completely wrong in every aspect of it.

[00:03:00]
I thought I was being so logical in measuring the tradeoffs, but I wasn't. Where I said I was arguing in favor of that wonderful elegance? No, it turns out that's a really bad thing because it causes coupling of these clauses which should be independent. And that means that the code is not really brittle, that if you need to make a change to one clause, that's going to affect other clauses which can now be spilling into it.

[00:03:24]
So you're making the program harder to maintain, you're making it more likely to have bugs introduced to it as a result of its going through simple revisions. Because what what we should always be doing is trying to uncouple things, right? But this causes an implicit coupling, which is bad.

[00:03:43]
But even worse was when I said, that hardly ever happens. That's another way of saying it happens, right. And we don't want it to ever happen. It's not like we don't want it happen very often, we want it never to happen, because we want our programs to be perfect.

[00:03:57]
We can't tolerate it ever going wrong. This is System One talking. System One is terrible at math. System One gives most more weight than all. System One thinks zero and not very many are the same. They're not. Any time we're making mathematical arguments without any data, that's probably System One talking, and there's a really good chance we're wrong.

[00:04:23]
Cuz it's guessing, it doesn't know, and we do this all the time. So a good style can help produce better programs. Style should not be about personal preference or self-expression or taste. It should be about reducing your error rate. Every decision we make about how are we gonna code this thing, how we're gonna express this thing, it should be about how are we best going to make a program which is going to be perfect?

[00:04:52]
Because ultimately, that's the goal. Now we can get some clues about programming style from the literary style. The Romans wrote Latin all in uppercase with no word breaks or punctuation, and it worked for them. You can go to Rome and you can still see these letters, we call them Roman letters today, cuz that's what they used, engraved in stone, looks just like this, except they were writing in Latin, but it's the same letters.

[00:05:18]
And it worked for them. They had a very powerful civilization that took over a large part of the world, held it for centuries. Although there are ambiguities in this, for example I can read the third line as, now or db reaks. It's a possible reading, so those sorts of ambiguities can lead to errors.

[00:05:40]
But it worked for them for a long time, until Constantine establishes Christianity as the official religion of the Roman Empire. At this point it becomes necessary to make copies of these documents and distribute them all over the world. And the problem is, they don't have originals for any of those documents, all they have are copies of copies of copies of copies.

[00:06:00]
And it turns out, no two copies agree. That every time they are copied, they mutate. And that's a problem if you're trying to establish an institution that derives its authority from the word and nobody can know for certain what the word was. So medieval copyists introduce lowercase, word breaks, and punctuation into their manuscripts.

[00:06:21]
And these innovations helped reduce their error rate. It made it easier to copy a manuscript without introducing errors into it. And that was a really important innovation. It also unexpectedly made the manuscripts easier to read. So when Gutenberg begins printing with movable type, he copies those conventions and we're still using them.

[00:06:44]
We now have centuries of experience with literary style using lowercase, word breaks, and punctuation. In a particular way, we've all been trained since we were children to read and write in that style. And that turns out to be really valuable, that you can easily tell the difference between good writing and bad writing by, does it conform to this or not?

[00:07:07]
So good use of style can help reduce the occurrence of errors. One of my favorite style manuals in English is the Elements of Style. It's a little pamphlet that was self published by William Strunk about 100 years ago. It's since been updated by EB White and it needed to be updated because English has continued to evolve since then, but most of Strunk's advice is still really good.

[00:07:33]
And a number of computer scientists have used it as a model for writing books on programming style very, very effectively. So programs must communicate clearly to people. We should think of our programs as literary works. And it's at least as important that they communicate what they do to people as they do to the machine.

[00:07:56]
It's not good enough to write something that's really sloppy, thinking that, well, if I can get it past the compiler, I've done my work. Because, if the program's ever gonna be used more than once, it's gonna to be necessary for somebody to be able to understand it and make it better.

[00:08:11]
And so we need to make the programs communicate what they do in order to allow us to do that. Otherwise, we're setting ourselves up or others for failure.