JavaScript practically requires callback functions to do anything asynchronous. Unless you’re talking about generators, you really can’t get away from them. Callbacks are everywhere.

But someone recently asked a question about naming callback methods:

Yes, I do use different names for the callback parameter, depending on the circumstance. I believe naming is important as it provides a set of expectations. If your code breaks the expectations of the name, people will be confused and it will cause problems.

Early in my Node days, I would name every callback “cb” – short for “callback”. There are still times when I use this name, but it’s not my default anymore. Rather, I have a short list of parameter names to go with the following scenarios:

This is a general purpose name to use when you are creating an API that does asynchronous work, and allows the consumer of the API to receive the results of your work.

In node, the standard callback method includes an error as the first argument. This requires the consumer of the API to handle error scenarios before they can get data or whatever result from the API call.

Examples include loading data from a database, making an HTTP API call, sending a message to RabitMQ, etc. This is easily the most common name for callbacks, as most API development uses this kind of pattern.

Middleware implementations need a way to continue on to the next middleware method, when required. The most common name for this is “next”, and a single call to it will move the code forward. 

Beyond the specific use case, there is a significant difference in the implementation compared to generic “cb” callback methods. The “next” function is usually supplied by the middleware API, for the API consumer to call, which is the opposite of the typical “cb” callback. 

A common example of this is Express.js routers. I’ve also used the generic-middleware library to create my own Express-like middleware features in my Rabbus library. There are other implementations of middleware around, but the Express model is frequently used.

This method is similar to “next” in that it is provided by an API for the consumer code to call. Unlike the “next” method, though, it doesn’t move on to the next chunk of code to execute. Rather, it signals the completion of the current code, allowing the API internals to clean up any initialized resources it holds.

A common example is asynchronous unit tests, as shown above. Jasmine needs to know when the “beforeEach” and “it” assertion blocks have completed. By providing a “done” method as part of the API, the developer writing the test can tell Jasmine that the code is complete.

My Ocarina library uses this pattern to clean up Oracle cursors and connections, as another example. 

The above are three common callback names that I use in my code, whether I am creating an API to be consumed, or consuming an API with my code. 

This is not an exhaustive list of callback names, however. I have written plenty of code that used other names, and I’m sure I will do so again. 

For example, my Rabbus libary provides an “actions” object for several parts of its API. This object is little more than a collection of callback methods that the API provides to the consumer code. 

I’m sure there are dozens of other scenarios in which a new method name would be appropriate, as well.

So, what are your common callback method names, and in what scenarios are those named used?