{2/24}
Properly styled computer code is more easily read and understood by humans.
You may revisit the code you write later, or you may work on code with other people in the future. It’s important that your code is easily understood by yourself and others.
{3/24}
Consistency:
Code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Solidity code.
{4/24}
Indentation:
Use 4 spaces per indentation level.
Tabs or Spaces:
Spaces are the preferred indentation method.
Mixing tabs and spaces should be avoided.
{5/24}
Within a contract surround function declarations with a single blank line.
Blank lines may be omitted between groups of related one-liners (such as stub functions for an abstract contract)
{6/24}
Maximum Line Length:
Keeping lines under the PEP 8 recommendation to a maximum of 79 (or 99) characters helps readers easily parse the code.
Wrapped lines should conform to the following guidelines.
{7/24}
1. The first argument should not be attached to the opening parenthesis.
2. One, and only one, indent should be used.
3. Each argument should fall on its own line.
4. The terminating element, ); , should be placed on the final line by itself.
{8/24}
Assignment Statements:
{9/24}
Event Definitions and Event Emitters:
{10/24}
Imports:
Import statements should always be placed at the top of the file.
11/24
Order of Functions
Ordering helps readers identify which functions they can call and find the constructor and fallback definitions easier.
Functions should be grouped according to their visibility and ordered:
constructor
fallback function
external
public
internal
private
{12/24}
Control Structures:
The braces denoting the body of a contract, library, functions, and structs should: 👇
{13/24}
- open on the same line as the declaration
- close on their own line at the same indentation level as the beginning of the declaration.
- The opening brace should be proceeded by a single space.
{14/24}
The same recommendations apply to the control structures if, else, while, and for.
{15/24}
Additionally, there should be a single space between the control structures if, while, and for and the parenthetic block representing the conditional, as well as a single space between the conditional parenthetic block and the opening brace.
{16/24}
Function Declaration:
For short function declarations, it is recommended for the opening brace of the function body to be kept on the same line as the function declaration.
The closing brace should be at the same indentation level as the function declaration.
{17/24}
You should explicitly label the visibility of all functions, including constructors.
{18/24}
The visibility modifier for a function should come before any custom modifiers.
{19/24}
In variable declarations, do not separate the keyword mapping from its type by a space.
Do not separate any nested mapping keyword from its type by whitespace.
The blockchain-based economy is no longer a dream, It may become reality soon!
Who wants to live on Satoshi Island? 🚀
A Thread 🧵
The Vanuatu government announces its support for the Satoshi Island Community Project, a private crypto island where fiat isn't invited.
Satoshi Island is the megaproject crypto utopia in the South Pacific that recently disclosed to Cointelegraph its vision, progress.
Hot on the heels of news that they received 50,000 citizenship nonfungible token (NFT) applications, the prime minister of Vanuatu has given his blessing to “watching the development of Satoshi Island unfold.”