-
Notifications
You must be signed in to change notification settings - Fork 154
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
30 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
--- | ||
title: Smart contract best practices | ||
metaTitle: Smart contract best practices | ||
--- | ||
|
||
Here are some general best practices that you should follow when developing smart contracts with Plutus. | ||
|
||
**Knowing the objective of your smart contract** | ||
|
||
Know exactly what your smart contract should do and test it to ensure that it fulfills the objective. Does one exist already? and if so, what is different about this smart contract? | ||
|
||
**Naming** | ||
|
||
Choose a clear and meaningful name for your smart contract. Keep it simple and short and aim to include what the smart contracte does in its name. | ||
|
||
**Peer review of code** | ||
|
||
The benefits of code review are well known; reviewed code aims to be consistent across the project, defect-free, and optimized for performance. The knowledge of the code is shared among developers, reducing maintenance time and cost in the future. For smart contracts, correctness is absolutely crucial. | ||
|
||
**Testing on a testnet** | ||
|
||
You should always test your smart contracts on a testnet environment before you run them on the mainnet. Write as many test scenarios as you can and run several iterations of your tests. | ||
|
||
**Documenting test cases** | ||
|
||
Keep a list of the test cases that you run so that you have them for reference and verification purposes. | ||
|
||
**Consider Formal Verification** | ||
|
||
The subject of formal verification is too large to adequately cover here. You can assume that your code will run in a hostile environment where highly skilled, well-resourced and unscrupulous actors will be waiting to pounce on any vulnerability. |