Variable shadowing#

There are two cases of variable shadowing.

Case 1#

In VRF.sol there is vrfCoordinator state variable that shadows same name variable inherited from VRFConsumerBaseV2. Both of these store the same address.

Recommendation#

Remove the vrfCoordinator variable from CanvasVRF. Since the same address is stored in VRFConsumerBaseV2, which is inherited by CanvasVRF, there is no need to store it. The variable defined in CanvasVRF was public and was of type VRFCoordinatorV2Interface, while the one defined in VRFConsumerBaseV2 is private and of type address, meaning the code will need additional changes. You need to add a getter function if you want to be able to get the address from contract. Additionally, when making calls to vrfCoordinator you will have to use it like this: VRFCoordinatorV2Interface(vrfCoordinator). The gas consumption when using it like this is the same, since the difference of defining address as contract type and casting an address to a contract type is purely visual. Furthermore, this solution should use less gas because the vrfCoordinator defined in VRFConsumerBaseV2 is immutable, meaning it becomes a part of the code on deployment and does not require reading from storage.

Case 2#

In CanvasCollection.sol there is initialize function that takes name and symbol as arguments. The names of these two arguments are the same as the names of functions defined in ERC721AUpgradable, which is inherited by CanvasCollection.

Recommendation#

Rename name and symbol in initialize function to _name and _symbol.