Rigor Protocol contest - lucacez's results

Don't Initialize Variables with Default Value

Uninitialized variables are assigned with the types default value. Explicitly initializing a variable with it's default value costs unnecesary gas.

There are 7 instances of this issue:

File: contracts/Community.sol

624:         for (uint256 i = 0; i < _communities[_communityID].memberCount; i++) {

File: contracts/HomeFiProxy.sol

87:         for (uint256 i = 0; i < _length; i++) {

136:         for (uint256 i = 0; i < _length; i++) {

File: contracts/Project.sol

248:         for (uint256 i = 0; i < _length; i++) {

311:         for (uint256 i = 0; i < _length; i++) {

322:         for (uint256 i = 0; i < _length; i++) {

File: contracts/libraries/Tasks.sol

181:         for (uint256 i = 0; i < _length; i++) _alerts[i] = _self.alerts[i];

Cache Array Length Outside of Loop

Caching the array length outside a loop saves reading it on each iteration, as long as the array's length is not changed during the loop.

There are 1 instances of this issue:

File: contracts/Project.sol

603:             for (; i < _changeOrderedTask.length; i++) {

Use != 0 instead of > 0 for Unsigned Integer Comparison

When dealing with unsigned integer types, comparisons with != 0 are cheaper then with > 0.

There are 10 instances of this issue:

File: contracts/Community.sol

261:         if (projectPublished[_project] > 0) {

427:             _communities[_communityID].projectDetails[_project].lentAmount > 0

764:         require(_repayAmount > 0, "Community::!repay");

840:         if (_interestEarned > 0) {

File: contracts/Disputes.sol

107:             _actionType > 0 && _actionType <= uint8(ActionType.TaskPay),

File: contracts/HomeFi.sol

245:         return projectTokenId[_project] > 0;

File: contracts/Project.sol

195:         require(_cost > 0, "Project::!value>0");

380:         if (_leftOutTokens > 0) {

601:         if (_changeOrderedTask.length > 0) {

691:         if (_loopCount > 0) emit TaskAllocated(_tasksAllocated);

Use immutable for OpenZeppelin AccessControl's Roles Declarations

Access roles marked as constant results in computing the keccak256 operation each time the variable is used because assigned operations for constant variables are re-evaluated every time. Changing the variables to immutable results in computing the hash only once on deployment, leading to gas savings.

There are 7 instances of this issue:

File: contracts\Community.sol

175: bytes32 _hash = keccak256(_data);

213: bytes32 _hash = keccak256(_data);

530: bytes32 _hash = keccak256(_data);

File: contracts\Disputes.sol

91: keccak256(_data),

File: contracts\Project.sol

499: keccak256(_data),

795: bytes32 _hash = keccak256(_data);

836: bytes32 _hash = keccak256(_data);