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).
注解
NatSpec was inspired by Doxygen. While it uses Doxygen-style comments and tags, there is no intention to keep strict compatibility with Doxygen. Please carefully examine the supported tags listed below.
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 annontated 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.
NatSpec may also include annotations used by third-party tools. These are most likely accomplished via the @custom:<name>
tag, and a good use case is analysis and verification tools.
文档举例
Documentation is inserted above each contract
, interface
, library
, function
, and event
using the Doxygen notation format.
A public
state variable is equivalent to a function
for the purposes of NatSpec.
- 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 the Vyper documentation.
The following example shows a contract and a function using all available tags.
注解
NatSpec currently does NOT apply to public state variables (see solidity#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.
This may change in the future.
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.8.2 < 0.9.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
/// @custom:experimental This is an experimental contract.
contract Tree {
/// @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;
}
/// @notice Returns the amount of leaves the tree has.
/// @dev Returns only a fixed number.
function leaves() external virtual pure returns(uint256) {
return 2;
}
}
contract Plant {
function leaves() external virtual pure returns(uint256) {
return 3;
}
}
contract KumquatTree is Tree, Plant {
function age(uint256 rings) external override pure returns (uint256) {
return rings + 2;
}
/// Return the amount of leaves that this specific kind of tree has
/// @inheritdoc Tree
function leaves() external override(Tree, Plant) pure returns(uint256) {
return 3;
}
}
文档输出
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:
solc --userdoc --devdoc ex1.sol
And the output is below.
注解
Starting Solidity version 0.6.11 the NatSpec output also contains a version
and a kind
field. Currently the version
is set to 1
and kind
must be one of user
or dev
. In the future it is possible that new versions will be introduced, deprecating older ones.
用户文档
The above documentation will produce the following user documentation JSON file as output:
{
"version": 1,
"kind": "user",
"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 and not simply the function’s name.
开发者文档
Apart from the user documentation file, a developer documentation JSON file should also be produced and should look like this:
{
"version" : 1,
"kind" : "dev",
"author" : "Larry A. Gardner",
"details" : "All function calls are currently implemented without side effects",
"custom:experimental" : "This is an experimental contract.",
"methods" :
{
"age(uint256)" :
{
"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"
}