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
  • 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 493
  • Vulnerability46
  • Bug88
  • Security Hotspot24
  • Code Smell335

  • Quick Fix 61
Filtered: 17 rules found
symbolic-execution
    Impact
      Clean code attribute
        1. Locks should be released within the same method

           Bug
        2. A write lock should not be released when a read lock has been acquired and vice versa

           Bug
        3. First/Single should be used instead of FirstOrDefault/SingleOrDefault on collections that are known to be non-empty

           Code Smell
        4. JWT secret keys should not be disclosed

           Vulnerability
        5. Types allowed to be deserialized should be restricted

           Vulnerability
        6. Secure random number generators should not output predictable values

           Vulnerability
        7. Empty collections should not be accessed or iterated

           Bug
        8. Objects should not be disposed more than once

           Code Smell
        9. Calculations should not overflow

           Bug
        10. Arguments of public methods should be validated against null

           Code Smell
        11. Empty nullable value should not be accessed

           Bug
        12. Cipher Block Chaining IVs should be unpredictable

           Vulnerability
        13. Boolean expressions should not be gratuitous

           Code Smell
        14. Conditionally executed code should be reachable

           Bug
        15. Null pointers should not be dereferenced

           Bug
        16. Locks should be released on all paths

           Bug
        17. Password hashing functions should use an unpredictable salt

           Vulnerability

        First/Single should be used instead of FirstOrDefault/SingleOrDefault on collections that are known to be non-empty

        intentionality - clear
        maintainability
        Code Smell
        • symbolic-execution

        When working with collections that are known to be non-empty, using First or Single is generally preferred over FirstOrDefault or SingleOrDefault.

        Why is this an issue?

        More Info

        Using FirstOrDefault or SingleOrDefault on collections that are known to be non-empty is an issue due to:

        • Code Clarity and intent: When you use FirstOrDefault or SingleOrDefault, it implies that the collection might be empty, which can be misleading if you know it is not. It can be confusing for other developers who read your code, making it harder for them to understand the actual constraints and behavior of the collection. This leads to confusion and harder-to-maintain code.
        • Error handling: If the developer’s intend is for the collection not to be empty, using FirstOrDefault and SingleOrDefault can lead to subtle bugs. These methods return a default value (null for reference types and default for value types) when the collection is empty, potentially causing issues like NullReferenceException later in the code. In contrast, First or Single will throw an InvalidOperationException immediately if the collection is empty, making it easier to detect and address issues early in the development process.
        • Code coverage: Potentially, having to check if the result is null, you introduces a condition that cannot be fully tested, impacting the code coverage.

        Code examples

        Noncompliant code example

        var items = new List<int> { 1, 2, 3 };
        
        int firstItem = items.FirstOrDefault(); // Noncompliant, this implies the collection might be empty, when we know it is not
        

        Compliant solution

        var items = new List<int> { 1, 2, 3 };
        
        int firstItem = items.First(); // Compliant
        
          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
          10.8

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use