Terry Jones

Yesterday I was on a call with a friend who told me that when he enters a URL into an existing Chrome tab, the tab id changes. He asked if I’d ever seen that happening, and I said no. I told him his code was probably to blame :-)

Anyway, I wrote a quick Chrome extension, called Tabsanity, to log all 8 tab events with the tab ids, as well as to run a simple sanity check on tab ids after every tab event.

All the action is in the Javascript console for the background page.

To see if you’ve got the issue my friend has, open a tab and go to http://en.wikipedia.org/wiki/Virtual_private_network. In the JS console you’ll see the tab id. Now go to the URL location bar, enter nytimes.com, and go to that URL. If Chrome is behaving properly for you, the tab id involved wont change. If you have the issue, the console log will show you that Chrome (quickly) removes the existing tab, creates a new one, and loads the nytimes page – resulting in a different tab id. We were both running Chrome 23.0.1271.101 on a MacBook Air. The same behavior happens in Incognito Mode with all other extensions disabled, and regular mode.

You can install from this link or get the source on Github.

The famous 17th commandment in The Elements of Style is “Omit needless words”.

There should be an equivalent in programming, but for parentheses. Every time I see needless parens in a program I want to rip them out (unless they’re obviously there for formatting/readability reasons).

Community service message: Omit needless parens. When in doubt whether parens are needed, look up the precedence rules for the operators involved and only use parens if the default isn’t what you want.

Here’s why you shouldn’t use needless parens:

• The #1 reason is that you’re making your code more difficult to read for people who know the language better than you do. A more experienced programmer will see a red flag and look at your code more carefully than necessary because they will be trying to figure out why you used the extra parens and if there’s something non-obvious going on. When I come across code like that, I usually conclude that whoever wrote the code doesn’t know the language that well. My opinion of the code goes down. My reading speed goes down too because the needless parens, in my estimation, indicate an increased likelihood that programmer has done other (worse) things elsewhere.
• You don’t want to appear incompetent or lazy, or to slow down or put off people reading your code, right? (See above.)
• Putting in needless parens is heading down a slippery slope. How many levels of extra parens should you stop at? The only clear cut rule that makes sense is to stop at zero.
• If you pause to look up the precedence rules, you’ll make yourself a better programmer in the language in question. You’ll be able to read other people’s needless-parenthesis-free code with no problem. You can pen lofty holier-than-thou blog posts like this one.

Back in about 1985 I wrote a tiny shell script to print out operator precedence and associativity rules for C. When I started programming in Perl, I wrote one for it. Then one for Python and later one for Javascript. For your convenience, and as a reward for reading, I just stuck the 4 scripts up on Github.

A visual summary of my coding work in the last week, creating branches, working on them, merging them back into the FluidDB trunk.

Coding is what you do when you tire of dealing with other humans. You get to interact with a literal-minded idiot who slavishly follows your every wish. Unfortunately you have to specify *everything* down to the very last detail in order to get anything done. But at least it does what it’s told, which is comforting in a world where everyone selfishly insists on doing what *they* want. You should try it sometime, it’s very relaxing, and nice to be totally in control.