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: Variable Never Used

C/C++
Solidity

Abstract

This variable is never used.

Explanation

This variable is never used. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.

Example 1: In the following code, a copy-and-paste error has led to the same loop iterator (i) being used twice. The variable j is never used.


  int i,j;

  for (i=0; i < outer; i++) {
    for (i=0; i < inner; i++) {
      ...

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 563

[2] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 2.8

[3] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-1-3

[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 0.1.2, Rule 0.2.1, Rule 0.2.2, Rule 0.2.3, Rule 0.2.4

[5] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3050 CAT II

[6] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3050 CAT II

[7] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3050 CAT II

[8] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3050 CAT II

[9] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3050 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3050 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3050 CAT II

[12] Standards Mapping - Smart Contract Weakness Classification SWC-131

desc.structural.cpp.poor_style_variable_never_used

Abstract

The contract defines a variable but never uses it.

Explanation

Solidity permits variables to be declared and never used and although most of the time this does not directly point to a security vulnerability, it is a bad practice. It can cause noise and unnecessary gas consumption due to the required increased computation cycles.

Example 1: The following code declares the variable var1 of type A but never uses it.


contract Base {
    struct A { uint a; }
}

contract DerivedA is Base {
    A var1 = A(1);
    int internal j = 500;

    function call(int a) public {
        assign1(a);
    }

    function assign3(A memory x) public returns (uint) {
        return g[1] + x.a + uint(j);
    }
}