solidity

Solidity Best Practices

This guide outlines the definitive best practices for writing Solidity smart contracts, ensuring security, readability, and efficiency. Adhere to these rules for all new and refactored code.

1. Code Organization & Structure

1.1 File Header

Every Solidity file MUST start with an SPDX license identifier and a precise pragma statement. Pin to a specific, audited compiler version.

❌ BAD

pragma solidity ^0.8.0; // Vague pragma, allows minor version bumps
// No license
contract MyContract {}

✅ GOOD

// SPDX-License-Identifier: MIT
pragma solidity 0.8.29; // Pin to specific, audited compiler version
contract MyContract {}

1.2 Indentation & Whitespace

Use 4 spaces for indentation. Never use tabs. Maintain consistent spacing around operators and within control structures.

❌ BAD

function myFunction (uint256  _value) public {
if(_value > 0){ emit Event(_value);}
}

✅ GOOD

function myFunction(uint256 _value) public {
    if (_value > 0) {
        emit Event(_value);
    }
}

1.3 Blank Lines

Use two blank lines between top-level declarations (contracts, interfaces, libraries). Use one blank line between function declarations within a contract.

❌ BAD

contract A {}
contract B {}
contract C {
    function foo() public {}
    function bar() public {}
}

✅ GOOD

contract A {}


contract B {}


contract C {
    function foo() public {}

    function bar() public {}
}

1.4 Maximum Line Length

Keep lines under 120 characters. Wrap long lines with a single indent for arguments, placing the closing parenthesis/semicolon on its own line.

❌ BAD

function reallyLongFunctionName(address _arg1, uint256 _arg2, bytes32 _arg3, bool _arg4, string memory _arg5) public pure returns (bool) { return true; }

✅ GOOD

function reallyLongFunctionName(
    address _arg1,
    uint256 _arg2,
    bytes32 _arg3,
    bool _arg4,
    string memory _arg5
)
    public
    pure
    returns (bool)
{
    return true;
}