This post first appeared on the Fulcrum blog.
I would create an object, and then call
init() on it. The instance
needed some stuff done before I could use it.
This pattern of using
init() grew after I saw it in another class. The
init() (short for initialize) implies it is run first, to set
things up. Since I was currently looking at the internals of the
init() felt as good a name as any.
A simple example of this pattern is:
var song = new Song(“Another One Bites the Dust”); song.init(); song.play();
init() could be used to rewind the cassette tape, prepare the
instruments on stage, make a connection to the cloud server for
streaming, or… anything, really.
Once the pattern expanded through several other classes, reading my code
became more difficult. First, not all my classes had an
distinction on which classes did and did not was arbitrary.
Next, I had recently written this code, but I no longer held in my mind
the knowledge of what it did. The name
init() wasn’t helpful in
reminding me. It was a catchall. I had to look at the implementation of
init() to see what was happening. Some did a lot; some did only a
bit. The internals varied greatly from class to class, even though the
functions all shared the same name. That hinted that something was
Ben Orenstein recently spoke at the Denver.rb meetup group.
During the talk, he showed us a real-world method named
was something like 600 lines of convoluted, meandering code. With a name
like that, it could literally do anything and still be a fitting name.
It was a bad name because we could not make it worse. It was an
example of a god method.
He also mentioned the poor code quality was a sign that the people working on it just didn’t care, at least about that method. When we write software, we must actively care. When we don't, we quickly end up in the weeds.
This reminds of me the well-known quote by Phil Karlton:
There are only two hard things in Computer Science: cache invalidation and naming things.
A fantastic way to actively care about your software is to name things well. Even though it is difficult, the work of finding a fitting name keeps your software maintainable.
When we stop caring about one function, its quality slips, and that impacts other areas. It’s easy for that poor quality to spread to other pieces of code.
I’ve worked to rename the
init() functions to be more revealing of
their purpose and what they do. The code is now easier to read and
documents itself better.
var song = new Song(“Another One Bites the Dust”); song.beginStreaming(); song.play();
If you notice, like I did, that your code is hard to follow and harder to maintain, ask whether you have actively cared about it. Take some time to name things properly. Your future self and your co-workers will be glad you did.