TokenAndPresale Code Style Findings

TAP-01C: Inexistent Error Messages

Description:

The linked require checks are not accompanied by an error message rendering their debugging as well as audit validation illegible.

Example:

Copy
319function recoverbep20(address tokenAddress, uint256 tokenAmount) public onlyOwner  {
320    require(block.timestamp >= liquidityUnlock);
321    Ibep20(tokenAddress).transfer(_owner, tokenAmount);
322}

Recommendation:

We advise error messages to be introduced to these checks to ensure that they accurately represent the condition they are meant to evaluate.

Alleviation:

All require checks contain an error message in the new version of the codebase.

TAP-02C: Misleading Error Message

Description:

The error message here states "Hardcap will be reached" whereas it should state that it will be exceeded.

Example:

Copy
227require(msg.value >= 0.1 ether, "You sent less than 0.1 BNB");
228require(msg.value <= 25 ether, "You sent more than 25 BNB");
229require(ethSent < 750 ether, "Hard cap reached");
230require (msg.value.add(ethSent) <= 750 ether, "Hardcap will be reached");

Recommendation:

We advise the error message to be adjusted accordingly.

Alleviation:

The error message was properly reworded to not mislead users.

TAP-03C: Redundant Variable

Description:

The justTrigger variable will hold equivalent values to the moonMissionStarted variable throughout the contract's life and as such can be considered redundant.

Example:

Copy
312if(!isStopped)
313    isStopped = true;
314
315moonMissionStarted = true;
316justTrigger = true;

Recommendation:

We advise its instances to be replaced by the moonMissionStarted variable and it to be removed from the codebase.

Alleviation:

The justTrigger variable was properly replaced by its equivalent moonMissionStarted boolean.

TAP-04C: Unoptimized Variable Mutabilities

Description:

The former three variables are assigned to only once during the contract's constructor and are done so to value literals whereas the latter three are assigned similarly with the only difference being that they read the memory state at their assignment.

Example:

Copy
196constructor ()  {
197    _owner = _msgSender();
198    _name = "Trustworks";
199    _symbol = "TRUST";
200    _decimals = 18;
201    _totalSupply = 1000000 ether;
202    refundTime = block.timestamp.add(30 days);
203    liquidityUnlock = block.timestamp.add(365 days);
204    _balances[_owner] = _totalSupply; 
205    emit Transfer(address(0), _owner, _totalSupply);
206}

Recommendation:

We advise the former three to have their assignments relocated to their declarations and for them to be set to constant and we advise the latter three to have the immutable mutability specifier introduced, thus greatly optimizing the gas cost of the codebase.

Alleviation:

Our advice was heeded and the assignments were either relocated or adjusted to be immutable.

TAP-05C: Visibility Specifiers Missing

Description:

The linked contract declarations do not possess a visibility specifier explicitly set and thus are assigned one by the compiler automatically.

Example:

Copy
152using SafeMath for uint256;
153
154IPCS constant pancake =  IPCS(0x05fF2B0DB69458A0750badebc4f9e13aDd608C7F);
155IpancakeV2Factory constant pancakeFactory = IpancakeV2Factory(0xBCfCcbde45cE874adCB698cC183deBcF17952812);
156
157mapping (address => uint256) private _balances;
158
159mapping (address => mapping (address => uint256)) private _allowances;

Recommendation:

We advise explicit visibility specifiers to be set as different compilers may yield different results due to ambiguity between versions.

Alleviation:

Visibility specifiers have yet to be set to the linked variables.