3

I have a node app with a queue for processing jobs in the background. I have a file that exports a function which when run, creates a job in my queue. In that file, I also have the handler for this type of job. It looks like this:

const actuallyDoStuff = async (...) => {
    // code that takes time
};

queue.process('do_stuff', async (job, done) => {
  try {
    await actuallyDoTheStuff(job.data);
    done();
  } catch (err) {
    done(err);
  }
});

const doStuff = async () => {
  const job = queue.create('do_stuff', { ... });
  job.save();
};

module.exports = doStuff;

The thing is, they could be called the same if the other didn't exist. What I'm wondering is if you guys had some good naming practices for cases like this one. Some of the options I considered:

  • Adding a prefix to the function that actually does the work, like doDoStuff
  • Adding a suffix to the other function to specify that it's creating a background job, like doStuffBG

But I don't really like those options. What are your good practices for cases like this one?

5
  • 3
    doStuff is not actually doing the stuff here, is queue-ing the stuff. – Miyamoto Akira Feb 2 '18 at 9:27
  • Is the fact that doStuff queues the job for later processing an implementation detail, or part of its contract? – David Arno Feb 2 '18 at 9:35
  • 1
    A very important one. If I call a function/method thinking that once is returned the stuff has been done, but actually is going to take another five minutes, I need to know. – Miyamoto Akira Feb 2 '18 at 9:38
  • 4
    The distinction should be part of the name, for instance, frobnicate() vs. scheduleFrobnication(). – Kilian Foth Feb 2 '18 at 9:45
  • That's the thing, in this case, I see it more as an implementation detail. But it couldn't hurt to make it clear that's it's doing it just schedules the job – Thomas Groutars Feb 3 '18 at 10:50
8

Adding a prefix to the function that actually does the work, like doDoStuff

Don't do that. Or you'll end up with doStuff(), doDoStuff(), reallyDoStuff(), reallyReallyDoStuff() and reallyReallyDoDoStuffThisOneDoesTheWorkHonestlyISwear()

Take another look at your functions. Sure, they might both be named "DoStuff()" if the other one did not exists. But the other one does. So what is the difference between those two functions?

actuallyDoStuff() might be the one to carry the name doStuff() here. And doStuff() would actually be createJobInQueueToDoStuff().

Long function names are not your enemy. Characters are cheap. A compiler/interpreter does not care if you use 5 or 50 characters to name your functions. So give them good, intuitive names.

3
  • 1
    I like "characters are cheap". – user949300 Feb 2 '18 at 17:52
  • The concern of long names isn't the disk space or compilation time but the screen space they take up. I'm not saying that long names are bad and certainly not justifying creat, but there are real countervailing pressures to having long names. In this case, they likely aren't strong though, so there is little reason to spend much time finding a good compact name. – Derek Elkins left SE Feb 3 '18 at 0:37
  • @Derek Elkins It is indeed a balance act - signal-to-noise and screenspace need to be taken into account too. Thus the more "local" a function or variable, the shorter its name can be (e.g. for (int i = 0; i < foo; i++) is perfectly fine for short loops; if you several times do stuff involving "i", spread a 40LOCs, you should start considering giving it a longer name...) That said, the majority of time is spent reading code, so you should try optimize it for maximum readability (which includes using well-named functions, not too long, but long enough to be intuitive) – CharonX Feb 5 '18 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.