mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
203 lines
7.0 KiB
ReStructuredText
203 lines
7.0 KiB
ReStructuredText
.. _natspec:
|
|
|
|
##############
|
|
NatSpec Format
|
|
##############
|
|
|
|
Solidity contracts can use a special form of comments to provide rich
|
|
documentation for functions, return variables and more. This special form is
|
|
named the Ethereum Natural Language Specification Format (NatSpec).
|
|
|
|
This documentation is segmented into developer-focused messages and end-user-facing
|
|
messages. These messages may be shown to the end user (the human) at the
|
|
time that they will interact with the contract (i.e. sign a transaction).
|
|
|
|
It is recommended that Solidity contracts are fully annotated using NatSpec for
|
|
all public interfaces (everything in the ABI).
|
|
|
|
NatSpec includes the formatting for comments that the smart contract author will
|
|
use, and which are understood by the Solidity compiler. Also detailed below is
|
|
output of the Solidity compiler, which extracts these comments into a machine-readable
|
|
format.
|
|
|
|
.. _header-doc-example:
|
|
|
|
Documentation Example
|
|
=====================
|
|
|
|
Documentation is inserted above each ``class``, ``interface`` and
|
|
``function`` using the doxygen notation format.
|
|
|
|
- For Solidity you may choose ``///`` for single or multi-line
|
|
comments, or ``/**`` and ending with ``*/``.
|
|
|
|
- For Vyper, use ``"""`` indented to the inner contents with bare
|
|
comments. See `Vyper
|
|
documentation <https://vyper.readthedocs.io/en/latest/structure-of-a-contract.html#natspec-metadata>`__.
|
|
|
|
The following example shows a contract and a function using all available tags.
|
|
|
|
.. note::
|
|
|
|
NatSpec currently does NOT apply to public state variables (see
|
|
`solidity#3418 <https://github.com/ethereum/solidity/issues/3418>`__),
|
|
even if they are declared public and therefore do affect the ABI.
|
|
|
|
The Solidity compiler only interprets tags if they are external or
|
|
public. You are welcome to use similar comments for your internal and
|
|
private functions, but those will not be parsed.
|
|
|
|
.. code:: solidity
|
|
|
|
pragma solidity >=0.5.0 <0.8.0;
|
|
|
|
/// @title A simulator for trees
|
|
/// @author Larry A. Gardner
|
|
/// @notice You can use this contract for only the most basic simulation
|
|
/// @dev All function calls are currently implemented without side effects
|
|
contract Tree {
|
|
/// @author Mary A. Botanist
|
|
/// @notice Calculate tree age in years, rounded up, for live trees
|
|
/// @dev The Alexandr N. Tetearing algorithm could increase precision
|
|
/// @param rings The number of rings from dendrochronological sample
|
|
/// @return age in years, rounded up for partial years
|
|
function age(uint256 rings) external pure returns (uint256) {
|
|
return rings + 1;
|
|
}
|
|
}
|
|
|
|
.. _header-tags:
|
|
|
|
Tags
|
|
====
|
|
|
|
All tags are optional. The following table explains the purpose of each
|
|
NatSpec tag and where it may be used. As a special case, if no tags are
|
|
used then the Solidity compiler will interpret a `///` or `/**` comment
|
|
in the same way as if it were tagged with `@notice`.
|
|
|
|
=========== =============================================================================== =============================
|
|
Tag Context
|
|
=========== =============================================================================== =============================
|
|
``@title`` A title that should describe the contract/interface contract, interface
|
|
``@author`` The name of the author contract, interface, function
|
|
``@notice`` Explain to an end user what this does contract, interface, function
|
|
``@dev`` Explain to a developer any extra details contract, interface, function
|
|
``@param`` Documents a parameter just like in doxygen (must be followed by parameter name) function
|
|
``@return`` Documents the return variables of a contract's function function
|
|
=========== =============================================================================== =============================
|
|
|
|
If your function returns multiple values, like ``(int quotient, int remainder)``
|
|
then use multiple ``@return`` statements in the same format as the
|
|
``@param`` statements.
|
|
|
|
.. _header-dynamic:
|
|
|
|
Dynamic expressions
|
|
-------------------
|
|
|
|
The Solidity compiler will pass through NatSpec documentation from your Solidity
|
|
source code to the JSON output as described in this guide. The consumer of this
|
|
JSON output, for example the end-user client software, may present this to the end-user directly or it may apply some pre-processing.
|
|
|
|
For example, some client software will render:
|
|
|
|
.. code:: solidity
|
|
|
|
/// @notice This function will multiply `a` by 7
|
|
|
|
to the end-user as:
|
|
|
|
.. code:: text
|
|
|
|
This function will multiply 10 by 7
|
|
|
|
if a function is being called and the input ``a`` is assigned a value of 10.
|
|
|
|
Specifying these dynamic expressions is outside the scope of the Solidity
|
|
documentation and you may read more at
|
|
`the radspec project <https://github.com/aragon/radspec>`__.
|
|
|
|
.. _header-inheritance:
|
|
|
|
Inheritance Notes
|
|
-----------------
|
|
|
|
Currently it is undefined whether a contract with a function having no
|
|
NatSpec will inherit the NatSpec of a parent contract/interface for that
|
|
same function.
|
|
|
|
.. _header-output:
|
|
|
|
Documentation Output
|
|
====================
|
|
|
|
When parsed by the compiler, documentation such as the one from the
|
|
above example will produce two different JSON files. One is meant to be
|
|
consumed by the end user as a notice when a function is executed and the
|
|
other to be used by the developer.
|
|
|
|
If the above contract is saved as ``ex1.sol`` then you can generate the
|
|
documentation using:
|
|
|
|
.. code::
|
|
|
|
solc --userdoc --devdoc ex1.sol
|
|
|
|
And the output is below.
|
|
|
|
.. _header-user-doc:
|
|
|
|
User Documentation
|
|
------------------
|
|
|
|
The above documentation will produce the following user documentation
|
|
JSON file as output:
|
|
|
|
.. code::
|
|
|
|
{
|
|
"methods" :
|
|
{
|
|
"age(uint256)" :
|
|
{
|
|
"notice" : "Calculate tree age in years, rounded up, for live trees"
|
|
}
|
|
},
|
|
"notice" : "You can use this contract for only the most basic simulation"
|
|
}
|
|
|
|
Note that the key by which to find the methods is the function's
|
|
canonical signature as defined in the `Contract
|
|
ABI <Ethereum-Contract-ABI#signature>`__ and not simply the function's
|
|
name.
|
|
|
|
.. _header-developer-doc:
|
|
|
|
Developer Documentation
|
|
-----------------------
|
|
|
|
Apart from the user documentation file, a developer documentation JSON
|
|
file should also be produced and should look like this:
|
|
|
|
.. code::
|
|
|
|
{
|
|
"author" : "Larry A. Gardner",
|
|
"details" : "All function calls are currently implemented without side effects",
|
|
"methods" :
|
|
{
|
|
"age(uint256)" :
|
|
{
|
|
"author" : "Mary A. Botanist",
|
|
"details" : "The Alexandr N. Tetearing algorithm could increase precision",
|
|
"params" :
|
|
{
|
|
"rings" : "The number of rings from dendrochronological sample"
|
|
},
|
|
"return" : "age in years, rounded up for partial years"
|
|
}
|
|
},
|
|
"title" : "A simulator for trees"
|
|
}
|