I agree with him that it's good to include those extra parens in code you write. But if you're reading or debugging code you didn't write, it's important to know them. If you just assume the code means what it appears to mean, you'll skip right over even shallow bugs.
I haven't read any of Tim's code, so I don't know how readable it is. But I found that spending a lot of time reading other people's code dramatically improved the readability of my own code. I venture to guess that his code is a little opaque in places without meaning to be, as a result of his not spending much time reading other people's code.
> I found that spending a lot of time reading other people's code dramatically improved the readability of my own code.
This I wholeheartedly agree with. I spent the first five years of my career porting large hairy codebases from PCs to embedded devices, without the original programmers available, and that has given me a drastically different code style to a lot of people.
> I venture to guess that his code is a little opaque in places without meaning to be, as a result of his not spending much time reading other people's code.
Here you lose me. I went out of my way to avoid memorizing the operator precedence rules too well, so that when I saw a complex one-line expression I'd have to stop and pay attention. A lot of the time the subtle bugs creep in because the naked expressions flow in a way that looks seductively correct, and so with an easy knowledge of precedence it's easy to make the same mistake as the original author.
As Bjarne S once said about casting in C++, I want it to look ugly in the code because it's an ugly idea. I want my code-reading to stumble when I hit those long unparenthesized expressions, to make sure I pay attention.
I haven't read any of Tim's code, so I don't know how readable it is. But I found that spending a lot of time reading other people's code dramatically improved the readability of my own code. I venture to guess that his code is a little opaque in places without meaning to be, as a result of his not spending much time reading other people's code.