solidity

Solidity Foundry Development Best Practices

This document provides guidelines for writing smart contracts in Solidity using the Foundry framework. It adapts concepts from TypeScript best practices to suit Solidity's unique type system, execution environment, and Foundry's tooling.

Type System

• Use interfaces to define function signatures for external contract interactions (e.g., ERC20 interfaces).
• Prefer structs to group related data into a single unit (e.g., struct User { address addr; uint256 balance; }).
• Use enums to represent discrete states or options (e.g., enum Status { Pending, Active, Closed }).
• Leverage mappings for efficient key-value storage (e.g., mapping(address => uint256) balances).
• Use custom types (Solidity 0.8.8+) for clarity and type safety (e.g., type UserId is uint256;).

Naming Conventions

• Use PascalCase for contract, struct, enum, and interface names (e.g., MyContract, UserStruct).
• Use camelCase for function and variable names (e.g., transferFunds, userBalance).
• Use UPPER_CASE for constants (e.g., MAX_SUPPLY, FEE_PERCENT).
• Use descriptive names with auxiliary verbs where applicable (e.g., isPaused, hasRole).
• Prefix events with Log for clarity (e.g., event LogTransfer(address from, address to, uint256 amount)).

Code Organization

• Follow Foundry's default project structure:
  • src/ for smart contracts.
  • test/ for test files (use .t.sol suffix for test contracts).
  • script/ for deployment and interaction scripts written in Solidity.
  • lib/ for external dependencies (managed as git submodules).
• Keep related contracts in the same file or directory for logical grouping.
• Use libraries for reusable code (e.g., math operations, string utilities).
• Organize imports at the top of the file, grouped by source (e.g., local files, OpenZeppelin contracts).
• Include an SPDX license identifier at the top of each file (e.g., // SPDX-License-Identifier: MIT).