The addTreat
function, originally designed to map treat data by a string
name, is inefficient and lacks user-specific treat management. The current mapping(string => Treat)
approach leads to higher gas costs and does not support associating treats with specific users. The updated mapping structure, mapping(address => Treat[])
, resolves these issues by organizing treats per user, eliminating the need for the treatNames
array.
The use of mapping(string => Treat)
creates inefficiencies because string
is more expensive to use than simpler types like address
. Additionally, it prevents effective user-specific tracking, as all treats are stored globally by name, rather than being tied to individual users. The addTreat
function also pushes treat names into an unnecessary treatNames
array, further complicating the contract and increasing storage costs.
Gas Inefficiency: Using string
as the mapping key results in higher gas costs for storage and lookups.
Lack of User-Specific Tracking: The current design doesn’t allow treats to be tied to specific users, limiting flexibility.
Unnecessary Data Storage: The treatNames
array is redundant with treats now being tracked per user.
Manual Review
1: Switch Mapping to address
: Replace mapping(string => Treat)
with mapping(address => Treat[])
to store treats per user, improving gas efficiency and enabling user-specific treat management.
2: Remove treatNames
: Eliminate the redundant treatNames
array to reduce storage and simplify the contract.
3: Update addTreat
: Modify the addTreat
function to use the new mapping(address => Treat[])
structure, adding treats directly to a user’s array.
These changes ensure the contract is more efficient, user-friendly, and removes redundant data handling.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.