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: 58 rules found
since-c++20
    Impact
      Clean code attribute
        1. Aggregates should be initialized with braces in non-generic code

           Code Smell
        2. Coroutines should have well-defined exception behavior

           Bug
        3. "constexpr" literal operators should be "consteval".

           Code Smell
        4. "std::format" should be used instead of standard output manipulators

           Code Smell
        5. C++ formatting functions should be used instead of C printf-like functions

           Code Smell
        6. The result of "make_format_args" should be passed directly as an argument

           Bug
        7. Use "std::format" rather than "std::vformat" when the format string is known at compile time

           Code Smell
        8. "std::format" numeric types should be 0-padded using the numerical padding and not the character padding

           Bug
        9. Arguments corresponding to width and precision formatting options should be integers

           Bug
        10. Calls to "std::format" with a locale should use the "L" flag

           Code Smell
        11. "std::format" should not have unused arguments

           Code Smell
        12. "std::format" should not be missing indexes

           Bug
        13. Concatenated "std::format" outputs should be replaced by a single invocation

           Code Smell
        14. Width, alignment, and padding format options should be used consistently

           Code Smell
        15. Explicit argument indexing in "std::format" should be used only for non-trivial ordering

           Code Smell
        16. Generic iterator-based algorithms should be constrained

           Code Smell
        17. "std::declval" should not be used within requires-expression

           Code Smell
        18. Template should not be constrained with ad-hoc requires-expression

           Code Smell
        19. Type-constraints should not be used for forwarding reference parameters

           Bug
        20. Requires-expression should not contain unevaluated concept checks or type predicates

           Bug
        21. Use type-erased "coroutine_handle" when applicable

           Code Smell
        22. Coroutine should have co_return on each execution path or provide return_void

           Bug
        23. Thread local variables should not be used in coroutines

           Code Smell
        24. Use conditional suspension to resume current coroutine

           Code Smell
        25. Use symmetric transfer to switch execution between coroutines

           Code Smell
        26. "std::string_view" and "std::span" parameters should be directly constructed from sequences

           Code Smell
        27. Comparision operators ("<=>", "==") should be defaulted unless non-default behavior is required

           Code Smell
        28. "std::chrono" components should be used to operate on time

           Code Smell
        29. "std::has_single_bit" should be used to test if an integer is a power of two

           Code Smell
        30. Empty class members should be marked as "[[no_unique_address]]"

           Code Smell
        31. "std::to_address" should be used to convert iterators to raw pointers

           Code Smell
        32. "[[nodiscard]]" attributes on types should include explanations

           Code Smell
        33. Concept names should comply with a naming convention

           Code Smell
        34. "std::cmp_*" functions should be used to compare unsigned values with negative values

           Bug
        35. STL constrained algorithms with range parameter should be used when iterating over the entire range

           Code Smell
        36. "std::enable_if" should not be used

           Code Smell
        37. Cognitive Complexity of coroutines should not be too high

           Code Smell
        38. Coroutine names should comply with a naming convention

           Code Smell
        39. Cyclomatic Complexity of coroutines should not be too high

           Code Smell
        40. "std::source_location" should be used instead of "__FILE__", "__LINE__", and "__func__" macros

           Code Smell
        41. Function template parameters should be named if reused

           Code Smell
        42. "std::span" should be used for a uniform sequence of elements contiguous in memory

           Code Smell
        43. Operator spaceship "<=>" should be used to define comparable types

           Code Smell
        44. Redundant comparison operators should not be defined

           Code Smell
        45. "std::format" should be used instead of string concatenation and "std::to_string"

           Code Smell
        46. Coroutines should not have too many lines of code

           Code Smell
        47. "std::cmp_*" functions should be used to compare signed and unsigned values

           Code Smell
        48. "std::bit_cast" should be used to reinterpret binary representation instead of "std::memcpy"

           Code Smell
        49. "[[likely]]" and "[[unlikely]]" should be used instead of compiler built-ins

           Code Smell
        50. "std::midpoint" and "std::lerp" should be used for midpoint computation and linear interpolation

           Code Smell
        51. "starts_with" and "ends_with" should be used for prefix and postfix checks

           Code Smell
        52. "using enum" should be used in scopes with high concentration of "enum" constants

           Code Smell
        53. "contains" should be used to check if a key exists in a container

           Code Smell
        54. "std::is_constant_evaluated" and "if consteval" should only be used when necessary

           Bug
        55. "std::jthread" should be used instead of "std::thread"

           Code Smell
        56. "nodiscard" attributes on functions should include explanations

           Code Smell
        57. Elements in a container should be erased with "std::erase" or "std::erase_if"

           Code Smell
        58. Mathematical constants should not be hardcoded

           Code Smell

        Redundant comparison operators should not be defined

        intentionality - clear
        maintainability
        Code Smell
        • since-c++20
        • clumsy
        • pitfall

        Why is this an issue?

        C++20 introduces rewriting rules that enable defining only a few operator overloads in a class to be able to compare class instances in many ways:

        • the "spaceship" operator<=> can replace all the other comparison operators in most cases: The code a @ b (where @ is one of the following operators: <, <=, >, or >=) can be implicitly rewritten to use either a<=>b or b<=>a, and its three-way comparison semantics instead.
        • If operator== is defined, a!=b can be implicitly rewritten !(a==b)
        • If an operator<=> is defined as =default, a matching operator== is automatically generated if it does not already exist.

        If you define your own version of any particular comparison operator, e.g., operator< in addition to the operator<=>, it will supersede the compiler-generated version and might result in a surprising behavior with operator< semantics inconsistent with the semantics of other operators defined through operator<=>.

        In most cases, you will only have to define the following set of comparison operators in your class (possibly several of those sets, to allow for mixed-type comparison):

        • No comparison operator, if the class should not be compared, or
        • only operator== for classes that can only be compared for equality (and inequality), or
        • only operator<=>, defined as =default for fully comparable classes that only need to perform comparison member by member, or
        • both operator<=> and operator== when the comparison is more complex.

        This rule will raise an issue when a class is defined:

        • With an operator<=> and any of the four operators <, <=, >, >= defined with the same argument type.
        • With both operator== and operator!= defined for the same types.
        • With a defaulted operator<=> and a defaulted operator== with the same argument types defined.
        • With two operator<=> or two operator== that are declared with the same argument types in reverse order.

        Noncompliant code example

        Example with redundant operations in the same class:

        class A {
          int field;
          public:
            auto operator<=>(const A&) const = default;
            bool operator<(const A& other) const { // Noncompliant: this definition is redundant when operator<=> is present
              return field < other.field;
            }
            bool operator==(const A&) const = default; // Noncompliant: unnecessary, this line is added implicitly
        };
        

        Example with equivalent operations in different order:

        class MyStr {
          friend std::strong_ordering operator<=>(MyStr const &s1, std::string const &s2);
          friend std::strong_ordering operator<=>(std::string const &s1, MyStr const &s2); // Noncompliant, redundant with the previous line
        };
        

        Compliant solution

        The class has been reduced to a minimal set:

        class A {
          int field;
          public:
            auto operator<=>(const A&) const = default; // Compliant: operator== is implicitly generated, and expressions with < can be written
        };
        
        // The following code is valid:
        void f(A const &a1, A const &a2) {
          bool b1 = a1 == a2; // Uses implicitly generated operator==
          bool b2 = a1 != a2; // Uses implicitly generated operator==, rewritten as: !(a1 == a2)
          bool b3 = a1 < a2; // Rewritten as: (a1 <=> a2) < 0
          bool b4 = a1 >= a2; // Uses implicitly generated operator==
          bool b1 = a1 == a2; // Uses implicitly generated operator==
        }
        

        Only one order needs to be written

        class MyStr {
          friend std::strong_ordering operator<=>(MyStr const &s1, std::string const &s2); // Compliant
        };
        
        // The following code is valid
        void f(MyStr const &s1, std::string const &s2) {
          bool b1 = s1 < s2; // Rewritten as: (s1<=>s2) < 0
          bool b2 = s2 >= s1; // Rewritten as 0 >= (s1<=>s2);
        }
        
          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