MISRA C++:2008 Rule 0-1-3

A project shall not contain unused variables

Description

This checker is deactivated in a default Polyspace^® as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

Rule Definition

A project shall not contain unused variables.

Rationale

Presence of unused variables indicates that the wrong variable name might be used in the source code. Removing these variables reduces the possibility of the wrong variable being used in further development. Keep padding bits in bitfields unnamed to reduce unused variables in your project.

Polyspace Implementation

Polyspace reports a violation of this rule if:

• A local or global variable is declared or defined but not read in any source files of the project.

• A member variable of a structure or a class is declared or defined but not read or written in any source files of the project.

Troubleshooting

If you expect a rule violation but Polyspace does not report it, see Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

Incomplete Class Implementation

This example shows how unused variable can indicate issues in your code. The class MyClass manages three private strings and declares three getter functions for the strings in MyClass.h. The class is implemented in MyClass.cpp. In the implementation, two of the three getter functions are implemented. The incomplete implementation results in an unused variable and Polyspace reports a defect.

• MyClass.h:

  //MyClass.h
  #ifndef MYCLASS_H
  #define MYCLASS_H
  
  #include <string>
  
  class MyClass {
  private:
  	std::string string1;
  	std::string string2;
  	std::string string3; //Noncompliant
  
  public:
      const std::string& getString1() const;
      const std::string& getString2() const;
      const std::string& getString3() const;
  };
  
  #endif  // MYCLASS_H

• MyClass.cpp

  //MyClass.cpp
  #include "MyClass.h"
  
  const std::string& MyClass::getString1() const {
      return string1;
  }
  
  const std::string& MyClass::getString2() const {
      return string2;
  }

Correction — Complete Class Implementation

To fix the defect, complete the class implementation.

• MyClass.h:

  //MyClass.h
  #ifndef MYCLASS_H
  #define MYCLASS_H
  
  #include <string>
  
  class MyClass {
  private:
  	std::string string1;
  	std::string string2;
  	std::string string3;
  
  public:
      const std::string& getString1() const;
      const std::string& getString2() const;
      const std::string& getString3() const;
  };
  
  #endif  // MYCLASS_H

• MyClass.cpp

  //MyClass.cpp
  #include "MyClass.h"
  
  const std::string& MyClass::getString1() const {
      return string1;
  }
  
  const std::string& MyClass::getString2() const {
      return string2;
  }
  
  const std::string& MyClass::getString3() const {
      return string3;
  }

Use of Named Bit Field for Padding

#include <iostream>
struct S {
    unsigned char b1 : 3;
    unsigned char pad: 1;  //Noncompliant
    unsigned char b2 : 4;
};
void init(struct S S_obj)
{
    S_obj.b1 = 0;
    S_obj.b2 = 0;
}

In this example, the bit field pad is used for padding the structure. Therefore, the field is never read or written and causes a violation of this rule. To avoid the violation, use an unnamed field for padding.

#include <iostream>
struct S {
    unsigned char b1 : 3;
    unsigned char : 1;  //Compliant
    unsigned char b2 : 4;
};
void init(struct S S_obj)
{
    S_obj.b1 = 0;
    S_obj.b2 = 0;
}

Check Information

Group: Language Independent Issues

Category: Required

Version History

Introduced in R2018a