GOMDori security record

The variables `_to` , `_from` and `_spender` should be verified as non-zero values to prevent being mistakenly assigned as `address(0)` in the `transfer()` , `transferFrom()` and `approve()` functions respectively.

In the functions at the pointed locations, the `_value` is not checked to be grater than zero. Although zero-value transactions will not result in incorrect balances or allowance changes, these operations still consume gas and may serve as a vector for a Denial of Service (DoS) attack.

Contract `GOMD` is vulnerable to [a known ERC20 race condition issue](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), which could lead to token theft. When a user calls `approve()` for a second time on a spender that has already been allowed, the spender could call `transferFrom()` to transfer the previous value and still receive the authorization to transfer the new value.

If the amount exceeds balance then ```solidity=304 address burner = msg.sender; balances[burner] = balances[burner].sub(_value); ``` will revert, making the statement : ```solidity=303 require(_value <= balances[msg.sender]); ``` useless and redundant.

The contract has an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging as compiler-specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

The internal function `isContract()` is designed to check if an address is a contract address. However, it is not used within the contract. The function `isContract` serves to verify if a provided address pertains to a contract. Although, it does not make a distinction between a call stemming from a contract's constructor and a call from a contract instance. Consequently, relying on this function to bar a contract from invoking certain functions during its creation could potentially introduce security risks. Furthermore, the `isContract` function has been removed from OpenZeppelin's Address library. Thus, it's vital to stay updated with the breaking changes in the OpenZeppelin library to ensure that your code remains secure and functional. References for your consideration: 1. [OpenZeppelin Address Library](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol) 2. [Pull Request for the Removal of isContract](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3945)

The interface `TokenRecipient` is not called in the contract and contains only the `receiveApproval()` function which is not implemented anywhere in the contract.

The variable `initialSupply` is assigned but never used in the whole codebase.

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.