Since what matters is not how the code does it but what it does, would you consider wrapping a function with a different name just to clarify it's behavior in certain situations a good practice? Real life example with pseudo-code:Let's say I have a small module to generate hardware signals. Now naturally one expects to find somewhere in the API a function to start a signal once all the configurations are done and the hardware is ready to fire:startSignal(myProperlyConfiguredInstance);Now, my user would naturally ask himself what happens if this function is called multiple times. Does the code detects the signal is running and ignores the call?Does it throw an exception because it assumes it's an error to try to start the signal multiple times?Does it cause hardware glitches? Does is reset the hardware and starts a new signal?The obvious answer seems to be specific behavior should be in the doc but we all know how documentation seems to decay faster than we write it and clear code is better than clear doc.My solution to this problem was to do this:void restartSignal(Instance myInstance){     startSignal(myInstance);}Now it seems to me that it is clear that the intended behavior is the 4th bullet and my user doesn't have to ask himself this question; he can just call restart if the signal is running or start if it's not. But now I have redundant code which doesn't actually acomplishes anything no? It seems like I'm repeating myself and it's perfectly fine to call restart to start an idle signal and start on a running signal! Which do you prefer? Richer API vs simpler API that requires a peak at the doc / tests / source code?
Redundant function to clarify purpose?
design;readability;dry
would you consider wrapping a function with a different name just to clarify it's behavior in certain situations a good practice? Absolutely.The key thing here is that for almost all code, the interface matters more than the implementation. If it makes sense to have a Restart method in your interface, then add it. Because while it's true that for this class, today the implementations are the same... it's not exactly uncommon for other implementations of the interface to differ, or for changing requirements to cause your implementations to drift apart.All that said, I would do this as a relatively last resort. Having two different methods that do the same thing is a sign that my design/naming is poor. Users of the interface will often think What is the difference between these things?.