SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
C++

C++ static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your C++ code

  • All rules 674
  • Vulnerability13
  • Bug139
  • Security Hotspot19
  • Code Smell503

  • Quick Fix 91
Filtered: 10 rules found
redundant
    Impact
      Clean code attribute
        1. "constexpr" functions should not be declared "inline"

           Code Smell
        2. Declaration specifiers should not be redundant

           Bug
        3. "const" and "volatile" should not be used in "enum" declarations

           Code Smell
        4. "static" should not be used in unnamed namespaces

           Code Smell
        5. "inline" should not be used redundantly

           Code Smell
        6. Base class access specifiers should not be redundant

           Code Smell
        7. Access specifiers should not be redundant

           Code Smell
        8. Forward declarations should not be redundant

           Code Smell
        9. Redundant casts should not be used

           Code Smell
        10. Overriding member functions should do more than simply call the same member in the base class

           Code Smell

        Access specifiers should not be redundant

        intentionality - clear
        maintainability
        Code Smell
        Quick FixIDE quick fixes available with SonarQube for IDE
        • redundant
        • clumsy

        Why is this an issue?

        Redundant access specifiers should be removed because they needlessly clutter the code.

        Noncompliant code example

        struct S {
        public: // Noncompliant; does not affect any declaration
        private:
          void f1();
        private: // Noncompliant; does not change accessibility level
          void f2();
        private: // Noncompliant; does not affect any declaration
        };
        class C {
          void f1();
        private: // Noncompliant;  does not change accessibility level
          void f2();
        };
        

        Compliant solution

        struct S {
        private:
          void f1();
          void f2();
        };
        class C {
          void f1();
          void f2();
        };
        

        Exceptions

        An access specifier at the very beginning of a class or struct that matches the default access level is ignored even when it doesn’t change any accessibility levels.

        class C {
          private: // redundant but accepted
            // ...
        };
        struct S {
          public: // redundant but accepted
            // ...
        };
        

        Such a specifier is redundant but ignored to allow classes and structs to be described uniformly.

        class C {
          public:
            void call();
        
          protected:
            int delete();
        
          private:
            int code;
        };
        struct S {
          public: // redundant but accepted
            int sum();
        
          protected:
            int min();
        
          private:
            int count;
        };
        

        Additionally, many people use an access specifier not to change the access level but as a visual separator between member functions and member variables of a class. This rule does not raise an issue on this pattern:

        class C {
        public:
          void f1();
        
        private:
          void f2();
          void f3();
        
        private: // redundant but accepted: separates functions from variables
          int m1;
        
        }
        

        Finally, Qt meta-object system makes use of some custom (macro-based) access specifiers. Even when they have no impact on the access level of the following members according to the C++ definition, they are accepted as long as they differ in spelling:

        class Counter : public QObject {
          Q_OBJECT
        public:
          Counter() { m_value = 0; }
          int value() const { return m_value; }
        
        public slots: // equivalent to "public" but accepted
          void setValue(int value);
        
        signals: // equivalent to "public" but accepted
          void keyChanged(int newValue);
        
        signals: // Noncompliant; does not change accessibility level
          void valueChanged(int newValue);
        
        private:
          int m_key;
          int m_value;
        };
        
          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use