GIF Next

If nothing else is specified, use the OpenZeppeling Solidity coding guidelines and Solidity style guide.

Functions within a contract are orders as follows: constructor, receive function (if exists), fallback function (if exists), external, public, internal, private. Within a grouping, place the view and pure functions last. (from https://docs.soliditylang.org/en/latest/style-guide.html#order-of-functions)

Do not use require. Always use custom errors.

Put custom errors in the interface file (if it exists). Name the custom error Error<NameOfContract><NameOfError>. This helps to avoid duplicates. Example

Put events in the interface file (if it exists). Name the event Log<NameOfContract><NameOfEvent>. This helps to avoid duplicates. Example

Do not use structs as event parameters.

When creating a new contract file, use the same pragma and license (Apache-2.0) as the other contracts in the project.

Remove dead code and commented code blocks, except if it is obvious that it will be relevant again within a reasonable amount of time. The code is not lost, its always accessible in the git history.

Document all functions and events. See this page for more information.

When copying code or other form of documentation, check the license and make sure that the code is compatible with the Apache-2.0 license. Always keep a reference the source in the comments!

Document known limitations and shortcomings. If you cannot complete the code in time, add a TODO comment with a description of what is missing and create an issue for it.

Use TODO: and FIXME: comments to mark code that needs to be fixed or improved.

Include graphics and diagrams to explain complex concepts.

Keep documentation current. If you change the code, update the documentation as well.

Write meaningful commit messages and reference the issue number (#262) in the commit message.

Use the Check-Effect-Interact pattern. See here for more information.

Ensure proper authorization of the contracts. See this page for details.

Function arguments and return types: If using custom data types, make the name include the type by appending the Type to the argument name, e.g. function getInfo(NftId bundleNftId) instead of function getInfo(NftId bundleId). Background: Custom data types are lost when using the ABI or Typescript binding classes (e.g. instead of NftID a uint96 is used), so the type needs to be included in the name to make it clear what the argument is without having to look at the documentation or checking the solidity source code.

When naming a field or an attribute id and the context is not clear, call it nftId instead so its clear what type of id it is as there will be multiple ids for different kind of objects. Example: if you the function has a bundle nft id and a policy nft id as arguments, call them bundleNftId and policyNftId instead of id and policyId. In case of doubt, be a bit more verbose for the sake of clarity.

When naming things, remember that the code will likely be used in Javascript/Typescript as well, so avoid names that are reserved in Javascript/Typescript. A list of reserved words in Javascript can be found [here](https://www.w3schools.com/js/js_reserved.asp) and a list of reserved words in Typescript can be found [here](https://www.tektutorialshub.com/typescript/identifiers-keywords-in-typescript/).

Name custom errors Error<NameOfContract><NameOfError>.

Name events Log<NameOfContract><NameOfEvent>.

The name of test methods must be unique. Stick to the following naming convention: test_<ContractName>_<FunctionName>_<ContextIfNeeded>. Example: test_Product_calculatePremium or test_Product_underwrite_BalanceTooLow.