Puppy Raffle
AI First Flight #1
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Impact: low
Likelihood: low
Invalid

[I-02] Storage Variable Naming Convention (Readability + Standardization)

lyes_boudjabout

Description

The contract defines several storage variables as follows:

address[] public players;
uint256 public raffleDuration;
uint256 public raffleStartTime;
address public previousWinner;
address public feeAddress;
uint64 public totalFees = 0;
mapping(uint256 => uint256) public tokenIdToRarity;
mapping(uint256 => string) public rarityToUri;
mapping(uint256 => string) public rarityToName;

Per coding standards, storage variables should follow a consistent naming convention, typically using the prefix s_ to indicate that the variable is stored in contract storage. This helps developers quickly distinguish storage variables from local or memory variables, improving readability, maintainability, and reducing the risk of accidental misuse in complex contract logic

Risk

  • Severity: Low

  • Type: Maintainability / Readability

  • Impact: There is no direct security vulnerability. However, inconsistent naming may lead to confusion, misinterpretation of variable mutability, or accidental misuse when interacting with storage variables in functions.

Impact

  • Low security impact: Variables are correctly declared as storage by Solidity.

  • Maintainability: Using a s_ prefix makes it clear which variables reside in storage, which is important for understanding gas costs and contract behavior.

  • Best Practices: Aligns with widely adopted Solidity style guides and internal coding standards, improving overall code quality.

Proof of Concept

Current declaration:

address[] public players;
uint256 public raffleDuration;
uint256 public raffleStartTime;
address public previousWinner;
address public feeAddress;
uint64 public totalFees = 0;
mapping(uint256 => uint256) public tokenIdToRarity;
mapping(uint256 => string) public rarityToUri;
mapping(uint256 => string) public rarityToName;

Recommended renaming using the s_ prefix:

- address[] public players;
+ address[] public s_players;
- uint256 public raffleDuration;
+ uint256 public s_raffleDuration;
- uint256 public raffleStartTime;
+ uint256 public s_raffleStartTime;
- address public previousWinner;
+ address public s_previousWinner;
- address public feeAddress;
+ address public s_feeAddress;
- uint64 public totalFees = 0;
+ uint64 public s_totalFees = 0;
- mapping(uint256 => uint256) public tokenIdToRarity;
+ mapping(uint256 => uint256) public s_tokenIdToRarity;
- mapping(uint256 => string) public rarityToUri;
+ mapping(uint256 => string) public s_rarityToUri;
- mapping(uint256 => string) public rarityToName;
+ mapping(uint256 => string) public s_rarityToName;

Explanation

  • The - lines show the current variable declarations.

  • The + lines show the recommended naming convention with the s_ prefix.

  • All references to these variables in functions or contract logic should be updated accordingly. For example:

function getRaffleDuration() external view returns (uint256) {
- return raffleDuration;
+ return s_raffleDuration;
}

  • This ensures functional correctness while improving readability and maintainability.

Recommended Mitigation

  • Rename all storage variables to use the s_ prefix.

  • Update all references in the contract to match the new variable names to avoid compilation errors.

  • Document this naming convention in the project’s coding guidelines to enforce consistent usage across the codebase.

  • Optionally, review other storage variables in the contract to ensure naming consistency, improving overall code clarity and maintainability.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 4 hours ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!