As the one who implement this tool,
startHttpServer, you should be trying to make it the most simple, smooth and seamless to use...
The function's logic
Technically, by splitting
startHttpServer's logic into 2 functions and calling them separately, all what you do is moving
startHttpServer's idempotency into the code calling both functions instead... Furthermore, unless you wrap both logic in a third function (which is what does
startHttpServer in first place), this forces you to write unDRYed code, duplicating it exponentially everywhere you'd have to call
startHttpServer. In short,
startHttpServer has to call itself the
So my point is:
isHttpServerRunning function because this may be needed independently anyway...
startHttpServer making it use
isHttpServerRunning to define its next action accordingly...
Still, you can make
startHttpServer return any value the user of this function may need, eg:
0 => server starting failure
1 => server starting success
2 => server was started already
The function's naming
First of all, what is the primary goal of the user? To start HTTP server, right?
Fundamentally, there is no problem by intending to start something that have been started already, AKA
1*1=1. So, at least to me, calling it "
ensureHttpServerIsRunning" seems not critically needed, I'd care more about how long, natural and memorable the function's name is.
Now if you want to know how work in detail the function under the hood, there is the documentation or code source for that, I mean like for any other function from library/framework/API/etc...
You learn the function once while you write it multiple times...
So anyway, I'd stick with
startHttpServer which is shorter, simpler and more explicit than
startHttpServer), and yes, the term "idempotent" applies here well.