Kingdom: Code Quality
Poor code quality leads to unpredictable behavior. From a user's perspective that often manifests itself as poor usability. For an attacker it provides an opportunity to stress the system in unexpected ways.
Poor Style: Confusing Naming
Abstract
The class contains a field and a method with the same name.
Explanation
It is confusing to have a member field and a method with the same name. It makes it easy for a programmer to accidentally call the method when attempting to access the field or vice versa.
Example 1:
Example 1:
public class Totaller {
private int total;
public int total() {
...
}
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398, CWE ID 710
[2] Standards Mapping - Smart Contract Weakness Classification SWC-119
desc.structural.java.poor_style_confusing_naming.member_and_method
Abstract
The contract uses a shadowed variable which is ambiguous and prone to misuse.
Explanation
Solidity allows developers to ambiguously declare state variables. This means that even though two different variables in two different contexts can be declared with the same name, using them can lead to confusion and misuse.
This can happen both at the function level and at the inheritance level. For example, if Contract1 declares var1 and inherits from Contract2, which also declares a variable named var1, then the variable is ambiguous and can easily be confused with each other later in the smart contract execution.
Example 1: The following code uses inheritance and declares a state variable with the same name in both smart contracts. It can be hard to determine which is the actual
This can happen both at the function level and at the inheritance level. For example, if Contract1 declares var1 and inherits from Contract2, which also declares a variable named var1, then the variable is ambiguous and can easily be confused with each other later in the smart contract execution.
Example 1: The following code uses inheritance and declares a state variable with the same name in both smart contracts. It can be hard to determine which is the actual
hardcap of the token sale.
contract Tokensale {
uint hardcap = 10000 ether;
function Tokensale() { }
function fetchCap() public constant returns(uint) {
return hardcap;
}
}
contract Presale is Tokensale {
uint hardcap = 1000 ether;
function Presale() Tokensale() { }
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398, CWE ID 710
[2] Standards Mapping - Smart Contract Weakness Classification SWC-119
desc.structural.solidity.swc119