This post first appeared on the Fulcrum blog.

While recently writing some software in JavaScript, I noticed a pattern. 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 name init() (short for initialize) implies it is run first, to set things up. Since I was currently looking at the internals of the functions, 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();

Here, 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 init(). The 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 each 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 wrong.

Ben Orenstein recently spoke at the Denver.rb meetup group. During the talk, he showed us a real-world method named perform that 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.