Stupid method names -> Angry programmers

Which of these commands do you think installs package “spoon” if you don’t yet have package “spoon” on your computer:

“bundle install spoon”

or

“bundle update spoon”

Correct answer: “bundle update spoon”

I’ve correctly run “bundle update xyz” many times but today forgot and typed the more intuitive “bundle install xyz.” I realized my error as soon as I hit “Enter,” but it was too late.

I noticed the strange “success” message:

Your bundle is complete! It was installed into ./spoon

The path argument to bundle install is deprecated. It will be removed in version 1.1. Please use bundle install --path spoon instead.

So, “install spoon” does not install the package “spoon” but, instead, creates a “spoon” directory and re-installs all your packages there.

I figured I would just delete the “spoon” directory and run “bundle update.” But nothing worked.

A quick Google search revealed that Bundler didn’t just create the “spoon” directory but also made it the new default location for all my packages. Reversing the damage was easy. But this demonstrates the importance of naming objects and methods intelligently.

Naming methods to match users' intuition is very important, esp. if you’re creating an API thousands of programmers will use. If you’re going to make your package-installing software’s “install” command do something totally different than install a package, you shouldn’t assume the first parameter passed to “install” represents a new directory name the user wants to use as a non-standard package repository.

The Bundler folks eventually figured this out and will soon require “—path” between “bundle install” and the new directory name. But they should have avoided this confusion when they initially coded “bundle install” and “bundle update.”

Posted by James on Friday, June 17, 2011