Should one always know what an API is doing just by looking at the code?

Posted by markmnl on Programmers See other posts from Programmers or by markmnl
Published on 2014-06-03T04:27:36Z Indexed on 2014/06/03 9:34 UTC
Read the original article Hit count: 398

Recently I have been developing my own API and with that invested interest in API design I have been keenly interested how I can improve my API design.

One aspect that has come up a couple times is (not by users of my API but in my observing discussion about the topic): one should know just by looking at the code calling the API what it is doing.

For example see this discussion on GitHub for the discourse repo, it goes something like:

foo.update_pinned(true, true);

Just by looking at the code (without knowing the parameter names, documentation etc.) one cannot guess what it is going to do - what does the 2nd argument mean? The suggested improvement is to have something like:

foo.pin()
foo.unpin()
foo.pin_globally()

And that clears things up (the 2nd arg was whether to pin foo globally, I am guessing), and I agree in this case the later would certainly be an improvement.

However I believe there can be instances where methods to set different but logically related state would be better exposed as one method call rather than separate ones, even though you would not know what it is doing just by looking at the code. (So you would have to resort to looking at the parameter names and documentation to find out - which personally I would always do no matter what if I am unfamiliar with an API).

For example I expose one method SetVisibility(bool, string, bool) on a FalconPeer and I acknowledge just looking at the line:

falconPeer.SetVisibility(true, "aerw3", true);

You would have no idea what it is doing. It is setting 3 different values that control the "visibility" of the falconPeer in the logical sense: accept join requests, only with password and reply to discovery requests. Splitting this out into 3 method calls could lead to a user of the API to set one aspect of "visibility" forgetting to set others that I force them to think about by only exposing the one method to set all aspects of "visibility". Furthermore when the user wants to change one aspect they almost always will want to change another aspect and can now do so in one call.

© Programmers or respective owner

Related posts about programming-practices

Related posts about naming