You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A customer has noted that it is standard practice to properly document APIs, with specification of both success and all possible failure cases. This way, applications using the client will be easier to write, more complete, and more robust.
This is quite easy to do in Erlang using @doc tags above function definitions.
Going hand in hand with this, every function, whether part of the API or not, should have full type specs of expected returns using -type syntax, and pass dialyzer checks. This makes the documentation easier as well, and effectively proves the specifications by static analysis.
Inspired by Zendesk ticket #11805.
The text was updated successfully, but these errors were encountered:
Basho-JIRA
changed the title
Fully document API using comments and @edoc tags
Fully document API using comments and @edoc tags [JIRA: CLIENTS-563]
Sep 1, 2015
nerophon
changed the title
Fully document API using comments and @edoc tags [JIRA: CLIENTS-563]
Fully document API using comments and @doc tags [JIRA: CLIENTS-563]
Sep 1, 2015
A customer has noted that it is standard practice to properly document APIs, with specification of both success and all possible failure cases. This way, applications using the client will be easier to write, more complete, and more robust.
This is quite easy to do in Erlang using @doc tags above function definitions.
Going hand in hand with this, every function, whether part of the API or not, should have full type specs of expected returns using -type syntax, and pass dialyzer checks. This makes the documentation easier as well, and effectively proves the specifications by static analysis.
Inspired by Zendesk ticket #11805.
The text was updated successfully, but these errors were encountered: