docs: include NatSpec for each function in the Swaplace contract about swaplace-contracts HOT 6 CLOSED

In the link OpenZepelin, should I only study the file ERC-20.sol inside the "utils" folder? Which other files will be important for this task?

from swaplace-contracts.

Where can I create and insert the descriptions and requirements for the interface to remove them from the main contract?

from swaplace-contracts.

If the 'internal' and 'view' functions don't need an interface, is it not necessary to create descriptions and requirements if they are not connected with other contracts? Do we need to remove the front-end references to the 'internal' and 'view' functions?

from swaplace-contracts.

In the link OpenZepelin, should I only study the file ERC-20.sol inside the "utils" folder? Which other files will be important for this task?

Every single contract, doesn't matter the file, will have the same pattern, you can compare them and realize the similarities!

from swaplace-contracts.

Where can I create and insert the descriptions and requirements for the interface to remove them from the main contract?

Sorry, I didn't get the questions properly... Every function in the code has a NatSpec documentation on top of them, If the subject is still unclear, I highly recommend you search for a tutorial about NatSpec, which will clarify it for you

from swaplace-contracts.

If the 'internal' and 'view' functions don't need an interface, is it not necessary to create descriptions and requirements if they are not connected with other contracts? Do we need to remove the front-end references to the 'internal' and 'view' functions?

Interface (type of smart contract) should not be confused with the NatSpec documentation. Internal functions don't have an interface because external contracts cannot connect to them, neither they can be called from outside the blockchain but they still need documentation explaining what they do!

Public functions with a view header most times are not accessed by other smart contracts, take ERC721 for example, there is a public function called "name" to describe the contract name, but they are non-existant in the interface, because the name itself doesn't hold any values for other contracts to fetch. But function such as ownerOf, which describes who own a token, are commonly called to verify ownership in the ecosystem, thus it is available in the interface.

Since you are showing interest in the task, which is awesome, I think you should perhaps document everything first and them we can optimize based on the architecture of the contract!

from swaplace-contracts.