Solidity - Style Guide

Style Guide helps to maintain code layout consistent and make code more readable. Following are the best practices following while writing contracts with Solidity.
Indentation − Use 4 spaces instead of tab to maintain indentation level. Avoid mixing spaces with tabs.
Indentation − Use 4 spaces instead of tab to maintain indentation level. Avoid mixing spaces with tabs.
Two Blank Lines Rule − Use 2 Blank lines between two contract definitions.
Two Blank Lines Rule − Use 2 Blank lines between two contract definitions.
pragma solidity ^0.5.0;

contract LedgerBalance {
   //...
}
contract Updater {
   //...
}
One Blank Line Rule − Use 1 Blank line between two functions. In case of only declaration, no need to have blank lines.
One Blank Line Rule − Use 1 Blank line between two functions. In case of only declaration, no need to have blank lines.
pragma solidity ^0.5.0;

contract A {
   function balance() public pure;
   function account() public pure;
}
contract B is A {
   function balance() public pure {
      // ...
   }
   function account() public pure {
      // ...
   }
}
Maximum Line Length − A single line should not cross 79 characters so that readers can easily parse the code.
Maximum Line Length − A single line should not cross 79 characters so that readers can easily parse the code.
Wrapping rules − First argument be in new line without opening parenthesis. Use single indent per argument. Terminating element ); should be the last one.
Wrapping rules − First argument be in new line without opening parenthesis. Use single indent per argument. Terminating element ); should be the last one.
function_with_a_long_name(
   longArgument1,
   longArgument2,
   longArgument3
);
variable = function_with_a_long_name(
   longArgument1,
   longArgument2,
   longArgument3
);
event multipleArguments(
   address sender,
   address recipient,
   uint256 publicKey,
   uint256 amount,
   bytes32[] options
);
MultipleArguments(
   sender,
   recipient,
   publicKey,
   amount,
   options
);
Source Code Encoding − UTF-8 or ASCII encoding is to be used preferably.
Source Code Encoding − UTF-8 or ASCII encoding is to be used preferably.
Imports − Import statements should be placed at the top of the file just after pragma declaration.
Imports − Import statements should be placed at the top of the file just after pragma declaration.
Order of Functions − Functions should be grouped as per their visibility.
Order of Functions − Functions should be grouped as per their visibility.
pragma solidity ^0.5.0;

contract A {
   constructor() public {
      // ...
   }
   function() external {
      // ...
   }

   // External functions
   // ...

   // External view functions
   // ...

   // External pure functions 
   // ...

   // Public functions
   // ...

   // Internal functions
   // ...

   // Private functions
   // ...
}
Avoid extra whitespaces − Avoid whitespaces immediately inside parenthesis, brackets or braces. 
Avoid extra whitespaces − Avoid whitespaces immediately inside parenthesis, brackets or braces. 
Control structures − Braces should open on same line as declaration. Close on their own line maintaining the same indentation. Use a space with opening brace.
Control structures − Braces should open on same line as declaration. Close on their own line maintaining the same indentation. Use a space with opening brace.
pragma solidity ^0.5.0;

contract Coin {
   struct Bank {
      address owner;
      uint balance;
   }
}
if (x < 3) {
   x += 1;
} else if (x > 7) {
   x -= 1;
} else {
   x = 5;
}
if (x < 3)
   x += 1;
else
   x -= 1;
Function Declaration − Use the above rule for braces. Always add a visibility label. Visibility label should come first before any custom modifier. 
Function Declaration − Use the above rule for braces. Always add a visibility label. Visibility label should come first before any custom modifier. 
function kill() public onlyowner {
   selfdestruct(owner);
}
Mappings − Avoid whitespaces while declaring mapping variables.
Mappings − Avoid whitespaces while declaring mapping variables.
mapping(uint => uint) map;
mapping(address => bool) registeredAddresses;
mapping(uint => mapping(bool => Data[])) public data;
mapping(uint => mapping(uint => s)) data;
Variable declaration − Avoid whitespaces while declaring array variables.
Variable declaration − Avoid whitespaces while declaring array variables.
uint[] x;  // not unit [] x;
String declaration − Use double quotes to declare a string instead of single quote.
String declaration − Use double quotes to declare a string instead of single quote.
str = "foo";
str = "Hamlet says, 'To be or not to be...'";
Elements should be layout in following order.
Pragma statements
Pragma statements
Import statements
Import statements
Interfaces
Interfaces
Libraries
Libraries
Contracts
Contracts
Within Interfaces, libraries or contracts the order should be as −
Type declarations
Type declarations
State variables
State variables
Events
Events
Functions
Functions
Contract and Library should be named using CapWords Style. For example, SmartContract, Owner etc.
Contract and Library should be named using CapWords Style. For example, SmartContract, Owner etc.
Contract and Library name should match their file names.
Contract and Library name should match their file names.
In case of multiple contracts/libraries in a file, use name of core contract/library.
In case of multiple contracts/libraries in a file, use name of core contract/library.
Owned.sol
pragma solidity ^0.5.0;

// Owned.sol
contract Owned {
   address public owner;
   constructor() public {
      owner = msg.sender;
   }
   modifier onlyOwner {
      //....
   }
   function transferOwnership(address newOwner) public onlyOwner {
      //...
   }
}
Congress.sol
pragma solidity ^0.5.0;

// Congress.sol
import "./Owned.sol";

contract Congress is Owned, TokenRecipient {
   //...
}
Struct Names − Use CapWords Style like SmartCoin.
Struct Names
Event Names − Use CapWords Style like Deposit, AfterTransfer.
Event Names
Function Names − Use mixedCase Style like initiateSupply.
Function Names
Local and State variables − Use mixedCase Style like creatorAddress, supply.
Local and State variables
Constants − Use all capital letters with underscore to seperate words like MAX_BLOCKS.
Constants
Modifier Names − Use mixCase Style like onlyAfter.
Modifier Names
Enum Names − Use CapWords Style like TokenGroup.
Enum Names

    38 Lectures 
     4.5 hours 

 Abhilash Nelson

    62 Lectures 
     8.5 hours 

 Frahaan Hussain

    31 Lectures 
     3.5 hours 

 Swapnil Kole
 Print
 Add Notes
 Bookmark this page