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: 81 rules found
cppcoreguidelines
    Impact
      Clean code attribute
        1. Function-like macros should not be used

           Code Smell
        2. Array type function arguments should not decay to pointers

           Code Smell
        3. The unary "&" operator should not be overloaded

           Code Smell
        4. Boolean operations should not have numeric operands, and vice versa

           Bug
        5. A cast shall not remove any const or volatile qualification from the type of a pointer or reference

           Code Smell
        6. "std::jthread" should be used instead of "std::thread"

           Code Smell
        7. Structured binding should be used

           Code Smell
        8. "dynamic_cast" should be used for downcasting

           Code Smell
        9. Threads should not be detached

           Code Smell
        10. Loop variables should be declared in the minimal possible scope

           Code Smell
        11. "shared_ptr" should not be taken by rvalue reference

           Code Smell
        12. Inheriting constructors should be used

           Code Smell
        13. Return type of functions shouldn't be const qualified value

           Code Smell
        14. "make_unique" and "make_shared" should be used to construct "unique_ptr" and "shared_ptr"

           Code Smell
        15. "std::endl" should not be used

           Code Smell
        16. C-style array should not be used

           Code Smell
        17. Objects should not be sliced

           Bug
        18. "auto" should be used to avoid repetition of types

           Code Smell
        19. Relational and subtraction operators should not be used with pointers to different arrays

           Bug
        20. Arguments evaluation order should not be relied on

           Bug
        21. STL algorithms and range-based for loops should be preferred to traditional for loops

           Code Smell
        22. Multiple mutexes should not be acquired with individual locks

           Code Smell
        23. Local variables should be initialized immediately

           Code Smell
        24. Pointers or references obtained from aliased smart pointers should not be used as function parameters

           Code Smell
        25. "try_lock", "lock" and "unlock" should not be directly used for mutexes

           Code Smell
        26. A single statement should not have more than one resource allocation

           Code Smell
        27. Function parameters that are rvalue references should be moved

           Code Smell
        28. Capture by reference in lambdas used locally

           Code Smell
        29. "Forwarding references" parameters should be used only to forward parameters

           Code Smell
        30. Non-const global variables should not be used

           Code Smell
        31. The order for arguments of the same type in a function call should be obvious

           Code Smell
        32. "std::move" and "std::forward" should not be confused

           Bug
        33. "using" should be preferred for type aliasing

           Code Smell
        34. "std::move" should only be used where moving can happen

           Code Smell
        35. Classes should not contain both public and private data members

           Code Smell
        36. Functions that throw exceptions should not be used as hash functions

           Code Smell
        37. A call to "wait()" on a "std::condition_variable" should have a condition

           Bug
        38. "std::move" should not inhibit optimizations

           Code Smell
        39. User-defined types should not be passed as variadic arguments

           Bug
        40. Template parameters should be preferred to "std::function" when configuring behavior at compile time

           Code Smell
        41. Function pointers should not be used as function parameters

           Code Smell
        42. RAII objects should not be temporary

           Bug
        43. Macros should not be used to define constants

           Code Smell
        44. Memory should not be managed manually

           Code Smell
        45. Lambdas that capture "this" should capture everything explicitly

           Code Smell
        46. Move and swap operations should be "noexcept"

           Code Smell
        47. "void *" should not be used in typedefs, member variables, function parameters or return type

           Code Smell
        48. Function parameters should not be of type "std::unique_ptr<T> const &"

           Code Smell
        49. "nullptr" should be used to denote the null pointer

           Code Smell
        50. Non-exception types should not be caught

           Code Smell
        51. Comparison operators should not be virtual

           Code Smell
        52. Local variables and member data should not be volatile

           Code Smell
        53. Assignment operators should not be "virtual"

           Code Smell
        54. Member variables should not be "protected"

           Code Smell
        55. Destructors should be "noexcept"

           Bug
        56. Types and variables should be declared in separate statements

           Code Smell
        57. Scoped enumerations should be used

           Code Smell
        58. "reinterpret_cast" should not be used

           Code Smell
        59. Special member function should not be defined unless a non standard behavior is required

           Code Smell
        60. "override" or "final" should be used instead of "virtual"

           Code Smell
        61. Member data should be initialized in-class or in a constructor initialization list

           Code Smell
        62. Members should be initialized in the order they are declared

           Code Smell
        63. Binary operators should be overloaded as hidden friend functions

           Code Smell
        64. Child class fields should not shadow parent class fields

           Code Smell
        65. Exception specifications should not be used

           Code Smell
        66. Type specifiers should be listed in a standard order

           Code Smell
        67. "explicit" should be used on single-parameter constructors and conversion operators

           Code Smell
        68. Functions without parameters should not use "(void)"

           Code Smell
        69. "operator delete" should be written along with "operator new"

           Bug
        70. Inherited functions should not be hidden

           Code Smell
        71. Pass by reference to const should be used for large input parameters

           Code Smell
        72. Assignment operators should return non-"const" reference to the assigned object

           Code Smell
        73. Polymorphic base class destructor should be either public virtual or protected non-virtual

           Code Smell
        74. C-style memory allocation routines should not be used

           Code Smell
        75. Generic exceptions should not be caught

           Code Smell
        76. "empty()" should be used to test for emptiness

           Code Smell
        77. Generic exceptions should never be thrown

           Code Smell
        78. Exception classes should be caught by reference

           Bug
        79. Function templates should not be specialized

           Code Smell
        80. Parameters in an overriding virtual function shall either use the same default arguments as the function they override, or else shall not specify any default arguments

           Code Smell
        81. "using namespace" directives should not be used in header files

           Code Smell

        Special member function should not be defined unless a non standard behavior is required

        consistency - conventional
        maintainability
        Code Smell
        Quick FixIDE quick fixes available with SonarQube for IDE
        • cppcoreguidelines
        • performance
        • since-c++11
        • clumsy

        Why is this an issue?

        More Info

        All special member functions (default constructor, copy and move constructors, copy and move assignment operators, destructor) can be automatically generated by the compiler if you don’t prevent it (for most classes, the good practice is to organize your code so that you can use these compiler generated versions, which is known as the "Rule of Zero").

        There are cases where it’s still useful to manually write such a function because the default implementation is not doing what you need. But when the manually written function is equivalent to the default implementation, this is an issue because:

        • It’s more code to write, test, and maintain for no good reason
        • Correctly writing the code of those functions is surprisingly difficult
        • Once you write one such function, you will typically have to write several (see S3624)
        • If you want your class to be trivial or to be an aggregate, those functions cannot be user-provided anyways

        In most cases, you should just remove the code of the redundant function. In some cases, the compiler will not automatically generate the default version of the function, but you can force it to do so by using the = default syntax.

        For default constructors, you can often use the default version if you use in-class initialization instead of the initializer list. You must make it explicitly defaulted if your class has any other constructor.

        For destructors, you may want to use the = default syntax in the following cases:

        • When you want to declare the destructor as virtual (see S1235).
        • When your class contains smart pointers to incomplete types, and you want to delay the destructor definition to the point where the types are complete. This commonly happens when using the PIMPL idiom. In that case, declare the destructor in the class and define it out-of-line with = default when the type is complete so that the smart pointer can properly delete them.

        This rule raises an issue when any of the following is implemented in a way equivalent to the default implementation:

        • default constructor
        • destructor
        • move constructor
        • move-assignment operator
        • copy constructor
        • copy-assignment operator

        Noncompliant code example

        struct Book {
          string Name;
        
          Book() { } // Noncompliant
          Book(const Book &Other) : Name(Other.Name) { } // Noncompliant
          Book &operator=(const Book &);
        };
        
        Book &Book::operator=(const Book &Other) { // Noncompliant
          Name = Other.Name;
          return *this;
        }
        

        Compliant solution

        struct Book {
          string Name;
        
          Book() = default; // Restores generation of default
          Book(const Book &Other) = default;
          Book &operator=(const Book &) = default;
        };
        
        // Or, more common:
        struct Book {
          string Name;
        };
        
          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