{"id":25862092,"url":"https://github.com/aboudjem/solidity-style-guide","last_synced_at":"2025-03-01T23:47:20.068Z","repository":{"id":243385751,"uuid":"812287498","full_name":"Aboudjem/solidity-style-guide","owner":"Aboudjem","description":"A comprehensive Solidity Style Guide to ensure consistent, readable, and maintainable smart contracts. Features include coding conventions, best practices for gas optimization and security, standardized naming, and effective documentation techniques. Ideal for developers seeking to improve their Solidity projects.","archived":false,"fork":false,"pushed_at":"2024-06-08T16:17:24.000Z","size":41,"stargazers_count":29,"open_issues_count":0,"forks_count":19,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-02-23T18:40:48.404Z","etag":null,"topics":["best-practices","coding-conventions","ethereum","foundry-testing","security-best-practices","smart-contracts","solidity","solidity-code","solidity-code-structure","solidity-documentation","solidity-naming-conventions","solidity-style-guide"],"latest_commit_sha":null,"homepage":"https://github.com/Aboudjem/solidity-style-guide/wiki","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Aboudjem.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-06-08T13:16:11.000Z","updated_at":"2025-02-16T17:04:02.000Z","dependencies_parsed_at":"2024-06-08T14:49:51.536Z","dependency_job_id":null,"html_url":"https://github.com/Aboudjem/solidity-style-guide","commit_stats":null,"previous_names":["aboudjem/solidity-style-guide"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Aboudjem%2Fsolidity-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Aboudjem%2Fsolidity-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Aboudjem%2Fsolidity-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Aboudjem%2Fsolidity-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Aboudjem","download_url":"https://codeload.github.com/Aboudjem/solidity-style-guide/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241439471,"owners_count":19963097,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["best-practices","coding-conventions","ethereum","foundry-testing","security-best-practices","smart-contracts","solidity","solidity-code","solidity-code-structure","solidity-documentation","solidity-naming-conventions","solidity-style-guide"],"created_at":"2025-03-01T23:47:18.874Z","updated_at":"2025-03-01T23:47:20.052Z","avatar_url":"https://github.com/Aboudjem.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Solidity Style Guide\n\n- [Solidity Style Guide](#solidity-style-guide)\n  - [Introduction](#introduction)\n    - [Purpose and Scope](#purpose-and-scope)\n    - [Evolution of the Guide](#evolution-of-the-guide)\n    - [Consistency over Correctness](#consistency-over-correctness)\n  - [General Coding Conventions](#general-coding-conventions)\n    - [Indentation and Spacing](#indentation-and-spacing)\n      - [Indentation Rules](#indentation-rules)\n      - [Tabs or Spaces](#tabs-or-spaces)\n      - [Blank Lines](#blank-lines)\n      - [Maximum Line Length](#maximum-line-length)\n      - [Source File Encoding](#source-file-encoding)\n    - [Use the Latest Version of Solidity](#use-the-latest-version-of-solidity)\n    - [Imports](#imports)\n  - [Code Structure](#code-structure)\n    - [Code Layout](#code-layout)\n    - [Order of Functions](#order-of-functions)\n    - [Order of Layout Elements](#order-of-layout-elements)\n    - [Single Contract or Interface Per File](#single-contract-or-interface-per-file)\n  - [Naming Conventions](#naming-conventions)\n    - [Naming Styles](#naming-styles)\n    - [Names to Avoid](#names-to-avoid)\n    - [Contract and Library Names](#contract-and-library-names)\n    - [Naming Interfaces](#naming-interfaces)\n    - [Defining Contract Types in Interfaces](#defining-contract-types-in-interfaces)\n    - [Struct Names](#struct-names)\n    - [Event Names](#event-names)\n    - [Function Names](#function-names)\n    - [Variable Names](#variable-names)\n    - [Function Argument Names](#function-argument-names)\n    - [Constants](#constants)\n    - [Modifier Names](#modifier-names)\n    - [Enums](#enums)\n    - [Avoiding Naming Collisions](#avoiding-naming-collisions)\n    - [Underscore Prefix for Non-external Functions and Variables](#underscore-prefix-for-non-external-functions-and-variables)\n  - [Code Formatting](#code-formatting)\n    - [Whitespace in Expressions](#whitespace-in-expressions)\n    - [Control Structures](#control-structures)\n    - [Function Declarations](#function-declarations)\n    - [Mappings](#mappings)\n    - [Variable Declarations](#variable-declarations)\n    - [Strings](#strings)\n    - [Operators](#operators)\n  - [Documentation](#documentation)\n    - [NatSpec Documentation](#natspec-documentation)\n  - [Best Practices](#best-practices)\n    - [Using Custom Errors Over Require](#using-custom-errors-over-require)\n    - [Require with Custom Error (Solidity 0.8.26+)](#require-with-custom-error-solidity-0826)\n    - [Limit Require Messages](#limit-require-messages)\n    - [Calldata for Read-Only Function Parameters](#calldata-for-read-only-function-parameters)\n    - [Optimize Length in Loops](#optimize-length-in-loops)\n    - [Prefer Named Return](#prefer-named-return)\n    - [Prefer Named Arguments](#prefer-named-arguments)\n    - [Prefer Named Parameters in Mapping Types](#prefer-named-parameters-in-mapping-types)\n    - [Enforcing Explicit Types](#enforcing-explicit-types)\n    - [Internal Function Naming](#internal-function-naming)\n    - [Contract Interactions Through Interfaces](#contract-interactions-through-interfaces)\n    - [Errors](#errors)\n    - [Events](#events)\n    - [Struct, Event and Error Definitions](#struct-event-and-error-definitions)\n    - [Upgradability](#upgradability)\n    - [Avoid Unnecessary Version Pragma Constraints](#avoid-unnecessary-version-pragma-constraints)\n    - [Avoid Using Assembly](#avoid-using-assembly)\n    - [Prefer Composition Over Inheritance](#prefer-composition-over-inheritance)\n  - [Testing (Foundry Specific)](#testing-foundry-specific)\n    - [Test Structure](#test-structure)\n    - [Unit Tests](#unit-tests)\n    - [Test Fixtures](#test-fixtures)\n    - [Mocking and Stubbing](#mocking-and-stubbing)\n    - [Property-Based Testing](#property-based-testing)\n    - [Gas Usage Testing](#gas-usage-testing)\n    - [Foundry Tools and Utilities](#foundry-tools-and-utilities)\n    - [General Test Guidance](#general-test-guidance)\n  - [Performance and Security](#performance-and-security)\n    - [Gas Optimization](#gas-optimization)\n    - [Security Best Practices](#security-best-practices)\n      - [Reentrancy](#reentrancy)\n      - [Access Control](#access-control)\n      - [Integer Overflow and Underflow](#integer-overflow-and-underflow)\n      - [Handling Ether Transfers](#handling-ether-transfers)\n    - [Code Reviews and Audits](#code-reviews-and-audits)\n  - [Conclusion](#conclusion)\n\n### Introduction\n\n#### Purpose and Scope\n\nThis guide is designed to provide coding conventions for writing Solidity code, ensuring consistency and readability. It is an evolving document that will adapt over time as new conventions are established and old ones become obsolete.\n\n\u003e [!NOTE]\n\u003e This guide is intended to extend, not replace, the official Solidity style guide, covering additional important aspects not addressed by the existing guidelines .\n\n#### Evolution of the Guide\n\nAs Solidity and its ecosystem evolve, so too will this style guide. It will incorporate new best practices, discard outdated ones, and adapt to the changing needs of the community.\n\n\u003e [!TIP]\n\u003e 💡 Regular updates ensure that the guide remains relevant and continues to promote the latest best practices in Solidity development .\n\n#### Consistency over Correctness\n\nThe primary goal of this guide is consistency, not necessarily correctness or the best way to write Solidity code. Consistency helps improve the readability and maintainability of codebases.\n\n\u003e [!IMPORTANT]\n\u003e \"A foolish consistency is the hobgoblin of little minds.\" Consistency with this guide is important, but consistency within a project or module is even more crucial. Use your best judgment and adapt as necessary .\n\nThis introductory section sets the stage for a comprehensive style guide, emphasizing the importance of adaptability, consistency, and extending existing best practices in Solidity coding.\n\n### General Coding Conventions\n\n#### Indentation and Spacing\n\n##### Indentation Rules\n\nUse 4 spaces per indentation level.\n\n\u003e [!TIP]\n\u003e 💡 Consistent indentation enhances code readability and structure, making it easier to follow and maintain.\n\n##### Tabs or Spaces\n\nSpaces are the preferred indentation method. Avoid mixing tabs and spaces.\n\n\u003e [!WARNING]\n\u003e ⚠️ Mixing tabs and spaces can lead to hard-to-debug errors. Stick to spaces for consistency.\n\n##### Blank Lines\n\n- Surround top-level declarations in Solidity with two blank lines.\n- Use a single blank line to separate function definitions within a contract.\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.0 \u003c0.9.0;\n\ncontract A {\n    // ...\n}\n\ncontract B {\n    // ...\n}\n\ncontract C {\n    // ...\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.0 \u003c0.9.0;\n\ncontract A {\n    // ...\n}\ncontract B {\n    // ...\n}\n\ncontract C {\n    // ...\n}\n```\n\nWithin 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).\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.6.0 \u003c0.9.0;\n\nabstract contract A {\n    function spam() public virtual pure;\n    function ham() public virtual pure;\n}\n\ncontract B is A {\n    function spam() public pure override {\n        // ...\n    }\n\n    function ham() public pure override {\n        // ...\n    }\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.6.0 \u003c0.9.0;\n\nabstract contract A {\n    function spam() virtual pure public;\n    function ham() public virtual pure;\n}\n\ncontract B is A {\n    function spam() public pure override {\n        // ...\n    }\n    function ham() public pure override {\n        // ...\n    }\n}\n```\n\n\u003e [!IMPORTANT]\n\u003e Proper spacing helps visually separate different sections of your code, making it easier to read and understand.\n\n##### Maximum Line Length\n\nLimit lines to a maximum of 120 characters. For long lines, follow these wrapping guidelines:\n\n1. Place the first argument on a new line.\n2. Use a single indentation level.\n3. Place each argument on its own line.\n4. Place the closing element on a new line.\n\n**Function Calls**\n\n**✅ Yes:**\n\n```solidity\nthisFunctionCallIsReallyLong(\n    longArgument1,\n    longArgument2,\n    longArgument3\n);\n```\n\n**❌ No:**\n\n```solidity\nthisFunctionCallIsReallyLong(longArgument1,\n                              longArgument2,\n                              longArgument3\n);\n\nthisFunctionCallIsReallyLong(longArgument1,\n    longArgument2,\n    longArgument3\n);\n\nthisFunctionCallIsReallyLong(\n    longArgument1, longArgument2,\n    longArgument3\n);\n\nthisFunctionCallIsReallyLong(\nlongArgument1,\nlongArgument2,\nlongArgument3\n);\n\nthisFunctionCallIsReallyLong(\n    longArgument1,\n    longArgument2,\n    longArgument3);\n```\n\n**Assignment Statements**\n\n**✅ Yes:**\n\n```solidity\nthisIsALongNestedMapping[being][set][toSomeValue] = someFunction(\n    argument1,\n    argument2,\n    argument3,\n    argument4\n);\n```\n\n**❌ No:**\n\n```solidity\nthisIsALongNestedMapping[being][set][toSomeValue] = someFunction(argument1,\n                                                                   argument2,\n                                                                   argument3,\n                                                                   argument4);\n```\n\n**Event Definitions and Event Emitters**\n\n**✅ Yes:**\n\n```solidity\nevent LongAndLotsOfArgs(\n    address sender,\n    address recipient,\n    uint256 publicKey,\n    uint256 amount,\n    bytes32[] options\n);\n\nemit LongAndLotsOfArgs(\n    sender,\n    recipient,\n    publicKey,\n    amount,\n    options\n);\n```\n\n**❌ No:**\n\n```solidity\nevent LongAndLotsOfArgs(address sender,\n                        address recipient,\n                        uint256 publicKey,\n                        uint256 amount,\n                        bytes32[] options);\n\nemit LongAndLotsOfArgs(sender,\n                  recipient,\n                  publicKey,\n                  amount,\n                  options);\n```\n\n\u003e [!CAUTION]\n\u003e 🚨 Long lines can be difficult to read and understand. Breaking them up improves clarity.\n\n##### Source File Encoding\n\nUse UTF-8 or ASCII encoding for Solidity files.\n\n\u003e [!NOTE]\n\u003e Consistent file encoding ensures compatibility and prevents encoding-related issues across different environments and tools.\n\n\u003e [!TIP]\n\u003e 💡 UTF-8 should be preferred over ASCII as it supports a wider range of characters.\n\n#### Use the Latest Version of Solidity\n\n**Rule:** Always use the latest stable version of Solidity. This version includes the most recent fixes, gas optimizations, and security improvements, ensuring your smart contracts are up-to-date with the best practices and latest advancements. This recommendation comes directly from the maintainers of the Solidity repository, who are responsible for the ongoing development and improvement of the language. While some tools like Slither might suggest using older versions, using the latest version is crucial for maximizing security and performance.\n\n\u003e [!TIP]\n\u003e 💡 Regularly check for updates and migrate your code to the latest stable version to take advantage of new features and enhancements in Solidity.\n\n#### Imports\n\nImport statements should always be placed at the top of the file.\n\n**A. Placing Imports**\n\nOrganize imports clearly at the top of the file to make dependencies easier to manage and understand.\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.0 \u003c0.9.0;\n\nimport \"./Owned.sol\";\n\ncontract A {\n    // ...\n}\n\ncontract B is Owned {\n    // ...\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.0 \u003c0.9.0;\n\ncontract A {\n    // ...\n}\n\nimport \"./Owned.sol\";\n\ncontract B is Owned {\n    // ...\n}\n```\n\n\u003e [!NOTE]\n\u003e Organizing imports clearly at the top of the file makes dependencies easier to manage and understand.\n\n**B. Use Named Imports**\n\nNamed imports or Selective Imports help readers understand what is being used and where it is declared.\n\n**✅ Yes:**\n\n```solidity\nimport {Ownable} from \"@openzeppelin/contracts/access/Ownable.sol\";\n```\n\n**❌ No:**\n\n```solidity\nimport \"@openzeppelin/contracts/access/Ownable.sol\";\n```\n\n\u003e [!NOTE]\n\u003e Named imports provide clarity on what is being imported, reducing potential confusion and making code review easier.\n\n**C. Order Imports by Path Length**\n\nOrder imports by the length of their paths, from shortest to longest, to maintain a clean and organized structure.\n\n**✅ Yes:**\n\n```solidity\nimport {Math} from \"./Math.sol\";\n\nimport {Ownable} from \"../access/Ownable.sol\";\nimport {ERC20} from \"../../token/ERC20.sol\";\n```\n\n**❌ No:**\n\n```solidity\nimport {Ownable} from \"../access/Ownable.sol\";\nimport {ERC20} from \"../../token/ERC20.sol\";\nimport {Math} from \"./Math.sol\";\n```\n\n\u003e [!TIP]\n\u003e 💡 Ordering imports by path length improves readability by maintaining a consistent structure, making it easier to locate and manage dependencies.\n\n**D. Group Imports by External and Internal**\n\nSeparate external and internal imports with a blank line and sort each group by path length.\n\n**✅ Yes:**\n\n```solidity\nimport {Ownable} from \"@openzeppelin/contracts/access/Ownable.sol\";\nimport {SafeMath} from \"@openzeppelin/contracts/math/SafeMath.sol\";\n\nimport {Math} from \"./Math.sol\";\nimport {MyHelper} from \"./helpers/MyHelper.sol\";\n```\n\n**❌ No:**\n\n```solidity\nimport {Math} from \"./Math.sol\";\nimport {MyHelper} from \"./helpers/MyHelper.sol\";\nimport {Ownable} from \"@openzeppelin/contracts/access/Ownable.sol\";\nimport {SafeMath} from \"@openzeppelin/contracts/math/SafeMath.sol\";\n```\n\n\u003e [!TIP]\n\u003e 💡 Grouping and sorting imports by their origin (external vs. internal) and path length keeps the codebase clean and well-organized, facilitating easier dependency management.\n\n### Code Structure\n\n#### Code Layout\n\nMaintain a consistent code layout to improve readability and organization. Structure your code with clear separations between different sections and use proper indentation and spacing.\n\n\u003e [!TIP]\n\u003e 💡 A well-organized layout helps developers quickly understand the structure and flow of the code.\n\n#### Order of Functions\n\nOrdering helps readers identify which functions they can call and to find the constructor and fallback definitions easier.\n\nFunctions should be grouped according to their visibility and ordered:\n\n- constructor\n- receive function (if exists)\n- fallback function (if exists)\n- external\n- public\n- internal\n- private\n\nWithin a grouping, place the `view` and `pure` functions last.\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.7.0 \u003c0.9.0;\n\ncontract A {\n    constructor() {\n        // ...\n    }\n\n    receive() external payable {\n        // ...\n    }\n\n    fallback() external {\n        // ...\n    }\n\n    // External functions\n    // ...\n\n    // External functions that are view\n    // ...\n\n    // External functions that are pure\n    // ...\n\n    // Public functions\n    // ...\n\n    // Internal functions\n    // ...\n\n    // Private functions\n    // ...\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.7.0 \u003c0.9.0;\n\ncontract A {\n\n    // External functions\n    // ...\n\n    fallback() external {\n        // ...\n    }\n    receive() external payable {\n        // ...\n    }\n\n    // Private functions\n    // ...\n\n    // Public functions\n    // ...\n\n    constructor() {\n        // ...\n    }\n\n    // Internal functions\n    // ...\n}\n```\n\n\u003e [!TIP]\n\u003e 💡 Grouping functions by visibility and type helps maintain a clear and organized contract structure.\n\n#### Order of Layout Elements\n\nArrange elements in the following order within contracts, libraries, or interfaces:\n\n1. Pragma statements\n2. Import statements\n3. Events\n4. Errors\n5. Interfaces\n6. Libraries\n7. Contracts\n\n\u003e [!NOTE]\n\u003e This ordering helps readers identify the structure and dependencies of the code more easily.\n\nInside each contract, library, or interface, use the following order:\n\n1. Type declarations\n2. State variables\n3. Events\n4. Errors\n5. Modifiers\n6. Functions\n\n\u003e [!NOTE]\n\u003e It might be clearer to declare types close to their use in events or state variables.\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.8.4 \u003c0.9.0;\n\nabstract contract Math {\n    error DivideByZero();\n    function divide(int256 numerator, int256 denominator) public virtual returns (uint256);\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.8.4 \u003c0.9.0;\n\nabstract contract Math {\n    function divide(int256 numerator, int256 denominator) public virtual returns (uint256);\n    error DivideByZero();\n}\n```\n\n#### Single Contract or Interface Per File\n\nEach Solidity file should contain only one contract or interface to simplify navigation and improve readability.\n\n\u003e [!TIP]\n\u003e 💡 Keeping a single contract or interface per file enhances maintainability and reduces complexity.\n\n### Naming Conventions\n\nNaming conventions are powerful when adopted and used broadly. The use of different conventions can convey significant _meta_ information that would otherwise not be immediately available.\n\nThe naming recommendations given here are intended to improve readability, and thus they are not rules, but rather guidelines to try and help convey the most information through the names of things.\n\nLastly, consistency within a codebase should always supersede any conventions outlined in this document.\n\n#### Naming Styles\n\nUse consistent naming styles to convey the purpose and scope of variables and functions:\n\n- `b` (single lowercase letter)\n- `B` (single uppercase letter)\n- `lowercase`\n- `UPPERCASE`\n- `SNAKE_UPPER_CASE`\n- `PascalCase`\n- `camelCase`\n\n\u003e [!NOTE]\n\u003e Consistent naming styles improve readability and help convey meta-information.\n\n\u003e [!NOTE]\n\u003e When using initialisms in PascalCase, capitalize all the letters of the initialisms. Thus `HTTPServerError` is better than `HttpServerError`. When using initialisms in camelCase, capitalize all the letters of the initialisms, except keep the first one lowercase if it is the beginning of the name. Thus `xmlHTTPRequest` is better than `XMLHTTPRequest`.\n\n#### Names to Avoid\n\nAvoid using names that are easily confused with each other or with numerals, such as `l`, `O`, and `I`.\n\n\u003e [!NOTE]\n\u003e Using ambiguous names can lead to confusion and errors.\n\n\u003e [!CAUTION]\n\u003e 🚨 Never use any of these for single letter variable names. They are often indistinguishable from the numerals one and zero.\n\n#### Contract and Library Names\n\n- Contracts and libraries should be named using the PascalCase style. Examples: `SimpleToken`, `SmartBank`, `CertificateHashRepository`, `Player`, `Congress`, `Owned`.\n- Contract and library names should also match their filenames.\n- If a contract file includes multiple contracts and/or libraries, then the filename should match the _core contract_. This is not recommended however if it can be avoided.\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.7.0 \u003c0.9.0;\n\n// Owned.sol\ncontract Owned {\n    address public owner;\n\n    modifier onlyOwner {\n        require(msg.sender == owner);\n        _;\n    }\n\n    constructor() {\n        owner = msg.sender;\n    }\n\n    function transferOwnership(address newOwner) public onlyOwner {\n        owner = newOwner;\n    }\n}\n```\n\nand in `Congress.sol`:\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.0 \u003c0.9.0;\n\nimport \"./Owned.sol\";\n\ncontract Congress is Owned, TokenRecipient {\n    //...\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.7.0 \u003c0.9.0;\n\n// owned.sol\ncontract owned {\n    address public owner;\n\n    modifier onlyOwner {\n        require(msg.sender == owner);\n        _;\n    }\n\n    constructor() {\n        owner = msg.sender;\n    }\n\n    function transferOwnership(address newOwner) public onlyOwner {\n        owner = newOwner;\n    }\n}\n```\n\nand in `Congress.sol`:\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.7.0;\n\nimport \"./owned.sol\";\n\ncontract Congress is owned, tokenRecipient {\n    //...\n}\n```\n\n\u003e [!TIP]\n\u003e 💡 Clear and consistent naming of contracts and libraries aids in project organization and readability.\n\n#### Naming Interfaces\n\n**Rule:** Interfaces should be named in a way that starts with `I` followed by the name of the contract it interfaces for, or you can use `ContractNameInterface`. Whichever naming convention you choose, you should stick to it.\n\n\u003e [!NOTE]\n\u003e Consistent naming of interfaces improves readability and helps in distinguishing between contracts and interfaces. This practice makes the code more intuitive and easier to navigate, especially in larger codebases.\n\n**Example:**\n\n**✅ Yes:**\n\n```solidity\ninterface IToken {\n    function transfer(address recipient, uint256 amount) external returns (bool);\n}\n```\n\nor\n\n```solidity\ninterface TokenInterface {\n    function transfer(address recipient, uint256 amount) external returns (bool);\n}\n```\n\n**❌ No:**\n\n```solidity\ninterface token {\n    function transfer(address recipient, uint256 amount) external returns (bool);\n}\n```\n\n#### Defining Contract Types in Interfaces\n\n**Rule:** Define all events, errors, structs, and optionally function names within interfaces for better modular organization and clarity.\n\n\u003e [!TIP]\n\u003e 💡 Grouping related types within interfaces enhances modularity and clarity, making it easier to manage and understand the structure of contracts.\n\n**Example:**\n\n**✅ Yes:**\n\n```solidity\ninterface IToken {\n    struct TokenData {\n        address issuer;\n        uint256 value;\n    }\n    error Unauthorized();\n    event TokenIssued(address indexed issuer, uint256 value);\n}\n\n// Usage in contract\ncontract Token is IToken {\n    // Implementation details\n}\n```\n\n**❌ No:**\n\n```solidity\ncontract Token {\n    struct TokenData {\n        address issuer;\n        uint256 value;\n    }\n    error Unauthorized();\n    event TokenIssued(address indexed issuer, uint256 value);\n}\n```\n\n#### Struct Names\n\nStructs should be named using PascalCase to distinguish them from variables and functions.\n\nExamples: `MyCoin`, `Position`, `PositionXY`.\n\n#### Event Names\n\nEvents should be named using PascalCase and should convey the past tense of an action.\nExamples: `ContractUpgraded`, `FundsDeposited`.`TransferCompleted`.\n\n\u003e [!NOTE]\n\u003e Clear event names improve the understanding of emitted logs.\n\n#### Function Names\n\nFunctions should use camelCase. Examples: `getBalance`, `transfer`, `verifyOwner`, `addMember`, `changeOwner`.\n\n#### Variable Names\n\nVariable names should use camelCase and be descriptive to convey their purpose.\n\nExamples: `totalSupply`, `remainingSupply`, `balancesOf`, `creatorAddress`, `isPreSale`, `tokenExchangeRate`.\n\n\u003e [!TIP]\n\u003e 💡 Descriptive names help in understanding the code without needing extensive comments.\n\n#### Function Argument Names\n\nFunction arguments should use camelCase. Examples: `initialSupply`, `account`, `recipientAddress`, `senderAddress`, `newOwner`.\n\nWhen writing library functions that operate on a custom struct, the struct should be the first argument and should always be named `self`.\n\n#### Constants\n\nName constants using all uppercase letters with underscores separating words, e.g., `MAX_SUPPLY`. If a constant is private, prefix it with an underscore.\n\nExamples of public constants:\n\n- `MAX_BLOCKS`\n- `TOKEN_NAME`\n- `TOKEN_TICKER`\n- `CONTRACT_VERSION`\n\nExamples of private constants:\n\n- `_MAX_BLOCKS`\n- `_TOKEN_NAME`\n- `_TOKEN_TICKER`\n- `_CONTRACT_VERSION`\n\n\u003e [!IMPORTANT]\n\u003e Consistent naming of constants using **SNAKE_UPPER_CASE** helps in quickly identifying them and prevents accidental modification. This practice enhances code readability and maintainability.\n\n\u003e [!TIP]\n\u003e 💡 Prefixing private constants with an underscore `_` clarifies their visibility and scope, aiding in code organization and readability.\n\n#### Modifier Names\n\nModifiers should use camelCase and clearly describe the condition they enforce, e.g., `onlyOwner`.\n\n#### Enums\n\nEnums should be named using PascalCase and clearly describe their purpose, e.g., `UserRole`.\n\n#### Avoiding Naming Collisions\n\nUse a single trailing underscore to avoid naming collisions with existing variables, functions, or reserved keywords, e.g., `variable_`.\n\n\u003e [!NOTE]\n\u003e Avoiding naming collisions reduces confusion and potential errors.\n\n\u003e [!TIP]\n\u003e 💡 Trailing underscores should be used primarily for parameters or variables that might otherwise collide with reserved keywords, functions, or other variables.\n\n#### Underscore Prefix for Non-external Functions and Variables\n\nPrefix non-external functions and variables with a single underscore to indicate they are internal or private, e.g., `_internalFunction`.\n\n\u003e [!IMPORTANT]\n\u003e Using an underscore prefix helps differentiate internal/private functions and variables from external ones, improving code clarity.\n\n- **\\_singleLeadingUnderscore**: This convention is used for non-external functions and state variables (`private` or `internal`). State variables without specified visibility are `internal` by default.\n\nWhen designing a smart contract, consider the public-facing API (functions callable by any account). Leading underscores help recognize the intent of non-external functions and variables. If you change a function from non-external to external (including `public`) and rename it, this forces a review of every call site, helping prevent unintended external functions and common security vulnerabilities.\n\n\u003e [!TIP]\n\u003e 💡 These conventions aim to create a consistent and readable codebase, making it easier to maintain and understand.\n\n### Code Formatting\n\n#### Whitespace in Expressions\n\nAvoid extraneous whitespace in the following situations:\n\nImmediately inside parentheses, brackets, or braces, with the exception of single-line function declarations.\n\n**✅ Yes:**\n\n```solidity\nspam(ham[1], Coin({name: \"ham\"}));\n```\n\n**❌ No:**\n\n```solidity\nspam( ham[ 1 ], Coin( { name: \"ham\" } ) );\n```\n\nException:\n\n```solidity\nfunction singleLine() public { spam(); }\n```\n\nImmediately before a comma, semicolon:\n\n**✅ Yes:**\n\n```solidity\nfunction spam(uint i, Coin coin) public;\n```\n\n**❌ No:**\n\n```solidity\nfunction spam(uint i , Coin coin) public ;\n```\n\nMore than one space around an assignment or other operator to align with another:\n\n**✅ Yes:**\n\n```solidity\nx = 1;\ny = 2;\nlongVariable = 3;\n```\n\n**❌ No:**\n\n```solidity\nx            = 1;\ny            = 2;\nlongVariable = 3;\n```\n\nDo not include whitespace in the receive and fallback functions:\n\n**✅ Yes:**\n\n```solidity\nreceive() external payable {\n    ...\n}\n\nfallback() external {\n    ...\n}\n```\n\n**❌ No:**\n\n```solidity\nreceive () external payable {\n    ...\n}\n\nfallback () external {\n    ...\n}\n```\n\n\u003e [!IMPORTANT]\n\u003e Avoiding unnecessary whitespace in expressions helps maintain clean and readable code.\n\n#### Control Structures\n\n- Place the opening brace `{` on the same line as the control structure.\n- Close the brace `}` on its own line.\n- Use a single space between the control structure keyword and the parenthesis.\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.0 \u003c0.9.0;\n\ncontract Coin {\n    struct Bank {\n        address owner;\n        uint balance;\n    }\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.0 \u003c0.9.0;\n\ncontract Coin\n{\n    struct Bank {\n        address owner;\n        uint balance;\n    }\n}\n```\n\nThe same recommendations apply to the control structures `if`, `else`, `while`, and `for`.\n\nAdditionally, 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.\n\n**✅ Yes:**\n\n```solidity\nif (...) {\n    ...\n}\n\nfor (...) {\n    ...\n}\n```\n\n**❌ No:**\n\n```solidity\nif (...)\n{\n    ...\n}\n\nwhile(...){\n}\n\nfor (...) {\n    ...;}\n```\n\nFor control structures whose body contains a single statement, omitting the braces is okay _if_ the statement is contained on a single line.\n\n**✅ Yes:**\n\n```solidity\nif (x \u003c 10)\n    x += 1;\n```\n\n**❌ No:**\n\n```solidity\nif (x \u003c 10)\n    someArray.push(Coin({\n        name: 'spam',\n        value: 42\n    }));\n```\n\nFor `if` blocks that have an `else` or `else if` clause, the `else` should be placed on the same line as the `if`'s closing brace. This is an exception compared to the rules of other block-like structures.\n\n**✅ Yes:**\n\n```solidity\nif (x \u003c 3) {\n    x += 1;\n} else if (x \u003e 7) {\n    x -= 1;\n} else {\n    x = 5;\n}\n\nif (x \u003c 3)\n    x += 1;\nelse\n    x -= 1;\n```\n\n**❌ No:**\n\n```solidity\nif (x \u003c 3) {\n    x += 1;\n}\nelse {\n    x -= 1;\n}\n```\n\n\u003e [!TIP]\n\u003e 💡 Consistent formatting of control structures improves readability and helps prevent errors.\n\n#### Function Declarations\n\n- For short functions, place the opening brace on the same line as the declaration.\n- For long functions, break each parameter onto a new line.\n- Use the order: visibility, mutability, virtual, override, and custom modifiers.\n\n**✅ Yes:**\n\n```solidity\nfunction increment(uint x) public pure returns (uint) {\n    return x + 1;\n}\n\nfunction increment(uint x) public pure onlyOwner returns (uint) {\n    return x + 1;\n}\n```\n\n**❌ No:**\n\n```solidity\nfunction increment(uint x) public pure returns (uint)\n{\n    return x + 1;\n}\n\nfunction increment(uint x) public pure returns (uint){\n    return x + 1;\n}\n\nfunction increment(uint x) public pure returns (uint) {\n    return x + 1;\n    }\n\nfunction increment(uint x) public pure returns (uint) {\n    return x + 1;}\n```\n\nThe modifier order for a function should be:\n\n1. Visibility\n2. Mutability\n3. Virtual\n4. Override\n5. Custom modifiers\n\n**✅ Yes:**\n\n```solidity\nfunction balance(uint from) public view override returns (uint) {\n    return balanceOf[from];\n}\n\nfunction increment(uint x) public pure onlyOwner returns (uint) {\n    return x + 1;\n}\n```\n\n**❌ No:**\n\n```solidity\nfunction balance(uint from) public override view returns (uint) {\n    return balanceOf[from];\n}\n\nfunction increment(uint x) onlyOwner public pure returns (uint) {\n    return x + 1;\n}\n```\n\nFor long function declarations, it is recommended to drop each argument onto its own line at the same indentation level as the function body. The closing parenthesis and opening bracket should be placed on their own line as well at the same indentation level as the function declaration.\n\n**✅ Yes:**\n\n```solidity\nfunction thisFunctionHasLotsOfArguments(\n    address a,\n    address b,\n    address c,\n    address d,\n    address e,\n    address f\n)\n    public\n{\n    doSomething();\n}\n```\n\n**❌ No:**\n\n```solidity\nfunction thisFunctionHasLotsOfArguments(address a, address b, address c,\n    address d, address e, address f) public {\n    doSomething();\n}\n\nfunction thisFunctionHasLotsOfArguments(address a,\n                                        address b,\n                                        address c,\n                                        address d,\n                                        address e,\n                                        address f) public {\n    doSomething();\n}\n\nfunction thisFunctionHasLotsOfArguments(\n    address a,\n    address b,\n    address c,\n    address d,\n    address e,\n    address f) public {\n    doSomething();\n}\n```\n\nIf a long function declaration has modifiers, then each modifier should be dropped to its own line.\n\n**✅ Yes:**\n\n```solidity\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n    public\n    onlyOwner\n    priced\n    returns (address)\n{\n    doSomething();\n}\n\nfunction thisFunctionNameIsReallyLong(\n    address x,\n    address y,\n    address z\n)\n    public\n    onlyOwner\n    priced\n    returns (address)\n{\n    doSomething();\n}\n```\n\n**❌ No:**\n\n```solidity\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n                                      public\n                                      onlyOwner\n                                      priced\n                                      returns (address) {\n    doSomething();\n}\n\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n    public onlyOwner priced returns (address)\n{\n    doSomething();\n}\n\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n    public\n    onlyOwner\n    priced\n    returns (address) {\n    doSomething();\n}\n```\n\nMultiline output parameters and return statements should follow the same style recommended for wrapping long lines found in the maximum line length section.\n\n**✅ Yes:**\n\n```solidity\nfunction thisFunctionNameIsReallyLong(\n    address a,\n    address b,\n    address c\n)\n    public\n    returns (\n        address someAddressName,\n        uint256 LongArgument,\n        uint256 Argument\n    )\n{\n    doSomething();\n\n    return (\n        veryLongReturnArg1,\n        veryLongReturnArg2,\n        veryLongReturnArg3\n    );\n}\n```\n\n**❌ No:**\n\n```solidity\nfunction thisFunctionNameIsReallyLong(\n    address a,\n    address b,\n    address c\n)\n    public\n    returns (address someAddressName,\n             uint256 LongArgument,\n             uint256 Argument)\n{\n    doSomething();\n\n    return (veryLongReturnArg1,\n            veryLongReturnArg1,\n            veryLongReturnArg1);\n}\n```\n\nFor constructor functions on inherited contracts whose bases require arguments, it is recommended to drop the base constructors onto new lines in the same manner as modifiers if the function declaration is long or hard to read.\n\n**✅ Yes:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.7.0 \u003c0.9.0;\n// Base contracts just to make this compile\ncontract B {\n    constructor(uint) {}\n}\n\ncontract C {\n    constructor(uint, uint) {}\n}\n\ncontract D {\n    constructor(uint) {}\n}\n\ncontract A is B, C, D {\n    uint x;\n\n    constructor(uint param1, uint param2, uint param3, uint param4, uint param5)\n        B(param1)\n        C(param2, param3)\n        D(param4)\n    {\n        // do something with param5\n        x = param5;\n    }\n}\n```\n\n**❌ No:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.7.0 \u003c0.9.0;\n\n// Base contracts just to make this compile\ncontract B {\n    constructor(uint) {}\n}\n\ncontract C {\n    constructor(uint, uint) {}\n}\n\ncontract D {\n    constructor(uint) {}\n}\n\ncontract A is B, C, D {\n    uint x;\n\n    constructor(uint param1, uint param2, uint param3, uint param4, uint param5)\n    B(param1)\n    C(param2, param3)\n    D(param4) {\n        x = param5;\n    }\n}\n\ncontract X is B, C, D {\n    uint x;\n\n    constructor(uint param1, uint param2, uint param3, uint param4, uint param5)\n        B(param1)\n        C(param2, param3)\n        D(param4) {\n            x = param5;\n        }\n}\n```\n\nWhen declaring short functions with a single statement, it is permissible to do it on a single line.\n\nPermissible:\n\n```solidity\nfunction shortFunction() public { doSomething(); }\n```\n\n\u003e [!TIP]\n\u003e 💡 These guidelines for function declarations are intended to improve readability. Authors should use their best judgment as this guide does not try to cover all possible permutations for function declarations.\n\n#### Mappings\n\nDo not separate the `mapping` keyword from its type with a space.\n\n**✅ Yes:**\n\n```solidity\nmapping(uint =\u003e uint) map;\nmapping(address =\u003e bool) registeredAddresses;\nmapping(uint =\u003e mapping(bool =\u003e Data[])) public data;\nmapping(uint =\u003e mapping(uint =\u003e s)) data;\n```\n\n**❌ No:**\n\n```solidity\nmapping (uint =\u003e uint) map;\nmapping( address =\u003e bool ) registeredAddresses;\nmapping (uint =\u003e mapping (bool =\u003e Data[])) public data;\nmapping(uint =\u003e mapping (uint =\u003e s)) data;\n```\n\n\u003e [!NOTE]\n\u003e Keeping `mapping` keywords without spaces ensures consistent formatting and readability.\n\n#### Variable Declarations\n\nDo not add a space between the type and the brackets for array variables.\n\n**✅ Yes:**\n\n```solidity\nuint[] x;\n```\n\n**❌ No:**\n\n```solidity\nuint [] x;\n```\n\n\u003e [!TIP]\n\u003e 💡 Consistent formatting of variable declarations helps in maintaining readability and avoids confusion.\n\n\u003e [!TIP]\n\u003e 💡 Consistent variable declarations prevent confusion and improve readability.\n\n#### Strings\n\nStrings should be quoted with double-quotes instead of single-quotes.\n\n**✅ Yes:**\n\n```solidity\nstring public greeting = \"Hello, World!\";\n```\n\n**❌ No:**\n\n```solidity\nstring public greeting = 'Hello, World!';\n```\n\n\u003e [!NOTE]\n\u003e Using double quotes for strings ensures consistency and aligns with common programming practices.\n\n#### Operators\n\nSurround operators with a single space on either side.\n\n**✅ Yes:**\n\n```solidity\nx = 3;\nx = 100 / 10;\nx += 3 + 4;\nx |= y \u0026\u0026 z;\n```\n\n**❌ No:**\n\n```solidity\nx=3;\nx = 100/10;\nx += 3+4;\nx |= y\u0026\u0026z;\n```\n\nOperators with a higher priority than others can exclude surrounding whitespace in order to denote precedence. This is meant to allow for improved readability for complex statements. You should always use the same amount of whitespace on either side of an operator:\n\n**✅ Yes:**\n\n```solidity\nx = 2**3 + 5;\nx = 2*y + 3*z;\nx = (a+b) * (a-b);\n```\n\n**❌ No:**\n\n```solidity\nx = 2** 3 + 5;\nx = y+z;\nx +=1;\n```\n\n\u003e [!TIP]\n\u003e 💡 Consistent spacing around operators enhances readability and ensures that code is easy to understand.\n\n### Documentation\n\n#### NatSpec Documentation\n\nSolidity contracts can also contain NatSpec comments. They are written with a triple slash (`///`) or a double asterisk block (`/** ... */`) and they should be used directly above function declarations or statements.\n\n**Example:**\n\n```solidity\n// SPDX-License-Identifier: GPL-3.0\npragma solidity \u003e=0.4.16 \u003c0.9.0;\n\n/// @author The Solidity Team\n/// @title A simple storage example\ncontract SimpleStorage {\n    uint storedData;\n\n    /// Store `x`.\n    /// @param x the new value to store\n    /// @dev stores the number in the state variable `storedData`\n    function set(uint x) public {\n        storedData = x;\n    }\n\n    /// Return the stored value.\n    /// @dev retrieves the value of the state variable `storedData`\n    /// @return the stored value\n    function get() public view returns (uint) {\n        return storedData;\n    }\n}\n```\n\nIt is recommended that Solidity contracts are fully annotated using NatSpec for all public interfaces (everything in the ABI).\n\n\u003e [!TIP]\n\u003e 💡 Proper documentation using NatSpec improves code maintainability and usability, especially for public APIs.\n\n\u003e [!NOTE]\n\u003e NatSpec should not be used only for public interfaces but also for any function that might be used by other developers, including internal APIs (functions).\n\n### Best Practices\n\n#### Using Custom Errors Over Require\n\n**Rule:** Utilize custom errors instead of `require` statements for clearer and more gas-efficient error handling. Solidity 0.8.26 supports the use of custom errors with `require`.\n\n**Example:**\n\n```solidity\nerror InsufficientFunds(uint256 requested, uint256 available);\n\nfunction withdraw(uint256 amount) public {\n    if (amount \u003e balance) {\n        revert InsufficientFunds(amount, balance);\n    }\n    balance -= amount;\n}\n```\n\n\u003e [!TIP]\n\u003e 💡 Custom errors save gas and provide more detailed error messages compared to traditional `require` strings.\n\n#### Require with Custom Error (Solidity 0.8.26+)\n\n**Rule:** Use the new `require(condition, error)` syntax to include custom errors in `require` statements, available in Solidity 0.8.26 and later.\n\n**Example:**\n\n```solidity\nerror InsufficientFunds(uint256 requested, uint256 available);\n\nfunction withdraw(uint256 amount) public {\n    require(amount \u003c= balance, InsufficientFunds(amount, balance));\n    balance -= amount;\n}\n```\n\n\u003e [!IMPORTANT]\n\u003e This new syntax provides a more efficient way to handle errors directly within `require` statements, enhancing both readability and gas efficiency.\n\n#### Limit Require Messages\n\n**Rule:** Prefer using custom errors over `require` with strings for better efficiency. If you must use `require` with a string message, keep it under 32 bytes to reduce gas costs.\n\n\u003e [!IMPORTANT]\n\u003e Custom errors are more gas-efficient and provide clearer error handling. Whenever possible, use them instead of `require` with a string message.\n\n**✅ Yes:**\n\n```solidity\nrequire(balance \u003e= amount, \"Insufficient funds\");\n```\n\n\u003e [!CAUTION]\n\u003e 🚨 Keeping `require` messages concise (under 32 bytes) minimizes additional gas costs and improves efficiency.\n\n**❌ No:**\n\n```solidity\nrequire(balance \u003e= amount, \"The balance is insufficient for the withdrawal amount requested.\");\n```\n\n\u003e [!WARNING]\n\u003e ⚠️ Longer messages significantly increase gas costs. Avoid using verbose messages in `require` statements.\n\n#### Calldata for Read-Only Function Parameters\n\n**Rule:** Using calldata can significantly reduce gas costs for external functions. It is beneficial for any external function, not just view functions, as long as the parameters are read-only.\n\n**✅ Yes:**\n\n```solidity\nfunction totalBalance(address[] calldata accounts) external view returns (uint256 total) {\n    for (uint i = 0; i \u003c accounts.length; i++) {\n        total += balances[accounts[i]];\n    }\n}\n```\n\n**❌ No:**\n\n```solidity\nfunction totalBalance(address[] memory accounts) external view returns (uint256 total) {\n    for (uint i = 0; i \u003c accounts.length; i++) {\n        total += balances[accounts[i]];\n    }\n}\n```\n\n\u003e [!TIP]\n\u003e 💡 Using `calldata` can significantly reduce gas costs for external functions. It is beneficial for any external function, not just view functions, as long as the parameters are read-only.\n\n#### Optimize Length in Loops\n\n**Rule:** Cache the length of arrays when used in loop conditions to minimize gas cost.\n\n**✅ Yes:**\n\n```solidity\nuint length = myArray.length;\nfor (uint i = 0; i \u003c length; i++) {\n    // Some logic\n}\n```\n\n**❌ No:**\n\n```solidity\nfor (uint i = 0; i \u003c myArray.length; i++) {\n    // Some logic\n}\n```\n\n\u003e [!CAUTION]\n\u003e 🚨 Accessing array length multiple times in a loop increases gas costs. Caching the length improves efficiency.\n\n#### Prefer Named Return\n\n**Rule:** Use named return arguments for gas efficiency and clarity, especially in functions with multiple return values.\n\n**✅ Yes:**\n\n```solidity\nfunction calculate(uint256 a, uint256 b) public pure returns (uint256 sum, uint256 product) {\n    sum = a + b;\n    product = a * b;\n}\n```\n\n**❌ No:**\n\n```solidity\nfunction calculate(uint256 a, uint256 b) public pure returns (uint256, uint256) {\n    uint256 sum = a + b;\n    uint256 product = a * b;\n    return (sum, product);\n}\n```\n\n\u003e [!TIP]\n\u003e 💡 Named return variables save gas by avoiding redundant return statements and making the code more readable.\n\n#### Prefer Named Arguments\n\n**Rule:** Use named arguments for function calls, events, and errors to improve clarity.\n\n**Example:**\n\n**✅ Yes:**\n\n```solidity\npow({base: x, exponent: y, scalar: v});\n```\n\n**❌ No:**\n\n```solidity\npow(x, y, v);\n```\n\n\u003e [!IMPORTANT]\n\u003e Explicitly naming arguments improves readability and reduces the chance of errors.\n\n#### Prefer Named Parameters in Mapping Types\n\n**Rule:** Explicitly name parameters in mapping types for clarity, especially when nesting is used.\n\n**✅ Yes:**\n\n```solidity\nmapping(address account =\u003e mapping(address asset =\u003e uint256 amount)) public balances;\n```\n\n**❌ No:**\n\n```solidity\nmapping(uint256 =\u003e mapping(address =\u003e uint256)) public balances;\n```\n\n\u003e [!TIP]\n\u003e 💡 Named parameters in mappings make the purpose and usage of the mappings clearer.\n\n#### Enforcing Explicit Types\n\n**Rule:** Always declare explicit types for all variable and function return declarations. Avoid using ambiguous types.\n\n**✅ Yes:**\n\n```solidity\nuint256 public balance;\nfunction getBalance() external view returns (uint256) {}\n```\n\n**❌ No:**\n\n```solidity\nuint balance = 256;  // Use explicit uint256\nfunction getBalance() external view returns (uint) {}  // Use explicit uint256\n```\n\n\u003e [!TIP]\n\u003e 💡 Using explicit types prevents ambiguity and ensures clarity in your code.\n\n#### Internal Function Naming\n\n**Rule:** Internal functions in a library should not have an underscore prefix.\n\n**Example:**\n\n**✅ Yes:**\n\n```solidity\nlibrary MathLib {\n    function add(uint256 a, uint256 b) internal pure returns (uint) {\n        return a + b;\n    }\n}\n\nusing MathLib for uint256;\nuint256 result = x.add(y);\n```\n\n**❌ No:**\n\n```solidity\nlibrary MathLib {\n    function _add(uint a, uint b) internal pure returns (uint) {\n        return a + b;\n    }\n}\n\nusing MathLib for uint;\nuint256 result = x._add(y);\n```\n\n\u003e [!IMPORTANT]\n\u003e Internal functions within libraries should be easy to read and follow, avoiding unnecessary prefixes.\n\n#### Contract Interactions Through Interfaces\n\n**Rule:** Whenever possible, interact with external contracts through well-defined interfaces. Direct contract calls should be avoided unless they offer specific benefits. If using `call`, prefer `abi.encodeWithSelector` to avoid issues.\n\n\u003e [!IMPORTANT]\n\u003e Using interfaces for external contract interactions enhances security by ensuring that only defined and expected methods are called, reducing the risk of unexpected behavior. This approach also makes the code more modular and easier to test.\n\n**Example:**\n\n**✅ Yes:**\n\n```solidity\ninterface IERC20 {\n    function transfer(address recipient, uint256 amount) external returns (bool);\n}\n\ncontract MyContract {\n    IERC20 private _token;\n\n    constructor(address tokenAddress) {\n        _token = IERC20(tokenAddress);\n    }\n\n    function transferToken(address recipient, uint256 amount) public {\n        _token.transfer(recipient, amount);\n    }\n}\n```\n\n**❌ No:**\n\n```solidity\ncontract MyContract {\n    address private _tokenAddress;\n\n    function transferToken(address recipient, uint256 amount) public {\n        (bool success, ) = _tokenAddress.call(abi.encodeWithSignature(\"transfer(address,uint256)\", recipient, amount));\n        require(success, \"Transfer failed.\");\n    }\n}\n```\n\n**Better Approach:**\n\n```solidity\ncontract MyContract {\n    address private _tokenAddress;\n\n    function transferToken(address recipient, uint256 amount) public {\n        (bool success, ) = _tokenAddress.call(abi.encodeWithSelector(IERC20.transfer.selector, recipient, amount));\n        require(success, \"Transfer failed.\");\n    }\n}\n```\n\n#### Errors\n\n**Rule:** Prefer custom errors over traditional error messages for better efficiency and clarity.\n\n**Naming Convention:** Custom error names should follow PascalCase.\n\n**Example:**\n\n```solidity\nerror InsufficientBalance(uint256 requested, uint256 available);\n```\n\n\u003e [!TIP]\n\u003e 💡 Use custom errors to save gas and make error handling more descriptive.\n\n#### Events\n\n**Rule:** Event names should be in past tense and follow the `SubjectVerb` format.\n\n**Example:**\n\n**✅ Yes:**\n\n```solidity\nevent OwnerUpdated(address newOwner);\n```\n\n**❌ No:**\n\n```solidity\nevent OwnerUpdate(address newOwner);\nevent UpdatedOwner(address newOwner);\n```\n\n\u003e [!NOTE]\n\u003e Consistent event naming helps understand contract behavior by reading the emitted events.\n\n#### Struct, Event and Error Definitions\n\n**Rule:** Declare structs, events and errors within their scope. If a struct or error is used across many files, define them in their own file. Multiple structs and errors can be defined together in one file.\n\n\u003e [!TIP]\n\u003e 💡 Centralize common structures, events and errors to improve maintainability and clarity.\n\n#### Upgradability\n\n**Rule:** Prefer the [ERC-7201](https://eips.ethereum.org/EIPS/eip-7201) \"Namespaced Storage Layout\" convention to avoid storage collisions.\n\n#### Avoid Unnecessary Version Pragma Constraints\n\n**Rule:** Avoid unnecessary version pragma constraints. While main contracts should specify a single Solidity version, supporting contracts and libraries should have as open a pragma as possible.\n\n**✅ Yes:**\n\n```solidity\npragma solidity ^0.8.0;\n```\n\n**❌ No:**\n\n```solidity\npragma solidity ^0.8.0 ^0.9.0;\n```\n\n\u003e [!TIP]\n\u003e 💡 Use open pragmas for supporting contracts and libraries to enhance compatibility and flexibility.\n\n#### Avoid Using Assembly\n\n**Rule:** Use inline assembly with extreme care. Ensure that it is well-documented with inline comments explaining what the assembly code does. Avoid using assembly unless it adds significant value and there are no better alternatives.\n\n**Example:**\n\n```solidity\nfunction add(uint x, uint y) public pure returns (uint result) {\n    assembly {\n        // Add x and y and store the result in the `result` variable\n        result := add(x, y)\n    }\n}\n```\n\n\u003e [!WARNING]\n\u003e ⚠️ Assembly code is hard to read and audit, increasing the risk of errors and vulnerabilities. Use it only when necessary and ensure thorough documentation to maintain code clarity and security.\n\n\u003e [!CAUTION]\n\u003e 🚨 Avoid using assembly if it does not provide significant performance or functional benefits. Always prefer high-level Solidity when possible.\n\n#### Prefer Composition Over Inheritance\n\n**Rule:** Prefer defining functions as part of a larger contract rather than creating many small contracts.\n\n\u003e [!NOTE]\n\u003e Inheritance is useful but should be used judiciously, especially when building on existing, trusted contracts like `Ownable` from OpenZeppelin.\n\n### Testing (Foundry Specific)\n\n#### Test Structure\n\nFoundry provides a flexible and efficient framework for structuring your tests. Here are the recommended structures:\n\n- **Unit Tests**\n\n  - Organize by contract or functionality:\n    - Treat contracts as describe blocks: e.g., `contract Add`, `contract Supply`.\n    - Have a test contract per contract-under-test: e.g., `contract MyContractTest`.\n  - **Example:**\n\n  ```solidity\n  contract Add {\n      function test_add_AddsTwoNumbers() public {\n          // Test code\n      }\n  }\n\n  contract MyContractTest {\n      function test_add_AddsTwoNumbers() public {\n          // Test code\n      }\n\n      function test_supply_UsersCanSupplyTokens() public {\n          // Test code\n      }\n  }\n  ```\n\n- **Integration Tests**\n  - Place in the same test directory.\n  - Clear naming convention to distinguish from unit tests.\n\n\u003e [!TIP]\n\u003e 💡 Organizing tests logically improves maintainability and makes it easier to identify and fix issues.\n\n#### Unit Tests\n\n- **Test Coverage**\n\n  - Ensure all functionalities are covered.\n  - Use `test_Description` for standard tests.\n  - Use `testFuzz_Description` for fuzz tests.\n  - Example:\n\n  ```solidity\n  function test_transfer() public {\n      // Test code\n  }\n\n  function testFuzz_transfer(uint amount) public {\n      // Test code\n  }\n  ```\n\n- **Test Naming Conventions**\n\n  - Consistent naming helps in filtering and identifying tests quickly.\n  - Example:\n\n  ```solidity\n  function test_RevertIf_Condition() public {\n      // Test code expecting revert\n  }\n\n  function testForkFuzz_RevertIf_Condition() public {\n      // Fuzz test with fork expecting revert\n  }\n  ```\n\n\u003e [!NOTE]\n\u003e Consistent naming aids in test management and improves readability.\n\n#### Test Fixtures\n\n- Use fixtures to set up common test scenarios.\n- Avoid making assertions in the `setUp` function. Instead, use a dedicated test like `test_SetUpState`.\n\n\u003e [!IMPORTANT]\n\u003e Isolating setup logic from assertions ensures clarity and reduces potential errors.\n\n#### Mocking and Stubbing\n\n- Utilize mocking and stubbing to simulate complex interactions and dependencies.\n- Example:\n\n  ```solidity\n  contract MockContract {\n      function mockedFunction() public returns (bool) {\n          return true;\n      }\n  }\n  ```\n\n\u003e [!TIP]\n\u003e 💡 Mocking and stubbing help in testing functionalities in isolation.\n\n#### Property-Based Testing\n\n- Foundry supports property-based testing to ensure that your contracts hold certain properties over a wide range of inputs.\n- Example:\n\n  ```solidity\n  function test_property(uint x) public {\n      assert(x \u003c 1000);\n  }\n  ```\n\n#### Gas Usage Testing\n\n- Monitor and optimize gas usage by incorporating gas usage tests.\n- Example:\n\n  ```solidity\n  function testGasUsage() public {\n      uint gasStart = gasleft();\n      // Function call\n      uint gasUsed = gasStart - gasleft();\n      emit log_named_uint(\"Gas used: \", gasUsed);\n  }\n  ```\n\n\u003e [!CAUTION]\n\u003e 🚨 Regular gas usage tests help in optimizing smart contract efficiency.\n\n#### Foundry Tools and Utilities\n\n- **Fuzz Testing**\n\n  - Foundry's fuzz testing tools help in identifying edge cases and potential issues.\n  - Example:\n\n  ```solidity\n  function testFuzz(uint x) public {\n      // Fuzz test code\n  }\n  ```\n\n- **Debugging with Foundry**\n\n  - Utilize Foundry's debugging tools to trace and fix issues.\n  - Example:\n\n  ```solidity\n  function testDebug() public {\n      // Debug test code\n  }\n  ```\n\n\u003e [!TIP]\n\u003e 💡 Leveraging Foundry's tools and utilities enhances test coverage and debugging capabilities.\n\n#### General Test Guidance\n\n- **File Naming**: For `MyContract.sol`, the test file should be `MyContract.t.sol`.\n- **Splitting Large Contracts**: Group logically, e.g., `MyContract.owner.t.sol`, `MyContract.deposits.t.sol`.\n- **Assertions**: Avoid assertions in `setUp`; use dedicated tests.\n- **Test Contracts**: Organize unit tests logically within contracts.\n\n\u003e [!NOTE]\n\u003e Consistent file naming and structure make it easier to locate and manage tests.\n\nThese practices and tools ensure comprehensive and efficient testing, leveraging Foundry's capabilities to maintain robust and reliable smart contracts.\n\n### Performance and Security\n\n#### Gas Optimization\n\nOptimizing gas usage is crucial for efficient and cost-effective smart contracts. Here are some best practices:\n\n- **Minimize Storage Operations**: Storage operations (SSTORE and SLOAD) are expensive. Minimize their usage by:\n  - Caching storage variables in memory.\n  - Using `calldata` for function parameters.\n- **Use Immutable and Constant**: Mark variables as `immutable` or `constant` where possible to save gas.\n- **Optimize Loops**: Cache array lengths and avoid unnecessary computations within loops.\n- **Prefer `uint256`**: Using `uint256` over smaller types like `uint8` or `uint32` can be more gas efficient due to padding.\n\n**Example:**\n\n```solidity\nuint immutable public value; // Immutable variable\nuint[] public data;\n\nfunction optimizedFunction(uint[] calldata input) external {\n    uint length = input.length; // Cache array length\n    for (uint i = 0; i \u003c length; i++) {\n        data.push(input[i]);\n    }\n}\n```\n\n#### Security Best Practices\n\nSecurity is paramount in smart contract development. Adhere to the following best practices to mitigate common vulnerabilities:\n\n##### Reentrancy\n\nReentrancy attacks occur when a contract calls an external contract before updating its state, allowing the external contract to call back into the original contract and manipulate its state. Prevent reentrancy by:\n\n- **Using Checks-Effects-Interactions Pattern**: Perform all state changes before calling external contracts.\n- **Reentrancy Guard**: Use a mutex or a reentrancy guard.\n\n**Example:**\n\n```solidity\nbool private locked;\n\nmodifier noReentrant() {\n    require(!locked, \"Reentrant call\");\n    locked = true;\n    _;\n    locked = false;\n}\n\nfunction withdraw(uint amount) external noReentrant {\n    require(balances[msg.sender] \u003e= amount, \"Insufficient balance\");\n    balances[msg.sender] -= amount;\n    (bool success, ) = msg.sender.call{value: amount}(\"\");\n    require(success, \"Transfer failed\");\n}\n```\n\n\u003e [!WARNING]\n\u003e ⚠️ Always perform state updates before calling external contracts to prevent reentrancy attacks.\n\n##### Access Control\n\nEnsure proper access control mechanisms are in place:\n\n- **Use `onlyOwner` Modifiers**: Restrict critical functions to the contract owner or specific roles.\n- **Role-Based Access Control**: Implement role-based access control (RBAC) for fine-grained permissions.\n\n**Example:**\n\n```solidity\naddress public owner;\nmapping(address =\u003e bool) public admins;\n\nmodifier onlyOwner() {\n    require(msg.sender == owner, \"Not owner\");\n    _;\n}\n\nmodifier onlyAdmin() {\n    require(admins[msg.sender], \"Not admin\");\n    _;\n}\n\nfunction addAdmin(address admin) external onlyOwner {\n    admins[admin] = true;\n}\n```\n\n\u003e [!TIP]\n\u003e 💡 Use libraries like OpenZeppelin's Access Control for robust access management.\n\n##### Integer Overflow and Underflow\n\nPrevent integer overflow and underflow by:\n\n- **Using SafeMath Library**: Use OpenZeppelin's `SafeMath` library for safe arithmetic operations.\n- **Solidity 0.8+**: Solidity 0.8 and later versions have built-in overflow and underflow checks.\n\n**Example:**\n\n```solidity\nusing SafeMath for uint256;\n\nfunction safeAdd(uint256 a, uint256 b) public pure returns (uint256) {\n    return a.add(b);\n}\n```\n\n\u003e [!CAUTION]\n\u003e 🚨 Always use safe arithmetic operations to prevent unexpected overflows and underflows.\n\n##### Handling Ether Transfers\n\nHandle Ether transfers securely by:\n\n- **Using `call` instead of `transfer` or `send`**: `call` provides more flexibility and forwards all available gas.\n- **Check Transfer Success**: Always check the return value of `call`.\n\n**Example:**\n\n```solidity\nfunction safeTransfer(address payable recipient, uint256 amount) internal {\n    (bool success, ) = recipient.call{value: amount}(\"\");\n    require(success, \"Transfer failed\");\n}\n```\n\n\u003e [!IMPORTANT]\n\u003e Properly handle Ether transfers to avoid vulnerabilities related to gas limits and failed transfers.\n\n#### Code Reviews and Audits\n\nRegular code reviews and security audits are essential for identifying and mitigating potential vulnerabilities:\n\n- **Internal Code Reviews**: Conduct regular internal reviews to catch issues early.\n- **External Audits**: Engage reputable auditing firms for comprehensive security audits.\n- **Automated Tools**: Use automated security analysis tools like [MythX](https://mythx.io/) or [Slither](https://github.com/crytic/slither) to scan for vulnerabilities.\n\n\u003e [!TIP]\n\u003e 💡 Regularly update and audit your contracts, especially after significant changes or before deployment.\n\nBy following these best practices, you can enhance the performance, security, and robustness of your Solidity smart contracts.\n\n### Conclusion\n\nThis Solidity Style Guide aims to enhance existing guidelines by providing additional, comprehensive information to ensure consistency, readability, and maintainability in your Solidity code. It draws inspiration from several valuable resources, which you can explore for further insights:\n\n- [Solidity Official Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html)\n- [Foundry Best Practices](https://book.getfoundry.sh/tutorials/best-practices)\n- [RareSkills Solidity Style Guide](https://www.rareskills.io/post/solidity-style-guide)\n- [Coinbase Solidity Style Guide](https://github.com/coinbase/solidity-style-guide/)\n\nThis guide is not intended to replace any existing style guides but to supplement them with additional best practices and recommendations.\n\nFeel free to contribute or make suggestions to this guide. Any pull requests or contributions are welcomed to help us continually improve.\n\nFor more updates and to connect with me, you can find me on social media:\n\n- [Twitter](https://twitter.com/adamboudj)\n- [GitHub](https://github.com/Aboudjem)\n- [LinkedIn](https://www.linkedin.com/in/adam-boudjemaa)\n- [Medium](https://medium.com/@adamboudj)\n\nThank you for using this guide, and happy coding!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faboudjem%2Fsolidity-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Faboudjem%2Fsolidity-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faboudjem%2Fsolidity-style-guide/lists"}