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
Go

Go static code analysis

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

  • All rules 94
  • Vulnerability21
  • Bug13
  • Security Hotspot14
  • Code Smell46
Filtered: 3 rules found
performance
    Impact
      Clean code attribute
        1. Context parameters should be reused instead of creating new background contexts

           Code Smell
        2. Use "bytes.Equal" instead of "bytes.Compare" for equality checks

           Code Smell
        3. Context cancellation functions should be deferred

           Code Smell

        Context cancellation functions should be deferred

        intentionality - complete
        reliability
        maintainability
        Code Smell
        • resource-management
        • performance

        This is an issue when using context.WithCancel, context.WithTimeout, or context.WithDeadline without deferring the returned cancel function.

        Why is this an issue?

        How can I fix it?

        More Info

        When you create a cancelable context using functions like context.WithCancel, context.WithTimeout, or context.WithDeadline, these functions return two values: a new context and a cancel function.

        The cancel function is crucial for proper resource management. It releases resources associated with the context, such as timers and goroutines. If you don’t call the cancel function, these resources may leak, leading to memory consumption and potential performance issues.

        The Go runtime cannot automatically clean up these resources because it doesn’t know when you’re done with the context. Only your code knows the appropriate time to release these resources.

        Using defer cancel() immediately after creating the context ensures that cleanup happens automatically when the function returns, regardless of how the function exits (normal return, early return, or panic). This follows the Go idiom of acquiring resources and immediately scheduling their cleanup.

        What is the potential impact?

        Failing to call the cancel function can lead to:

        • Memory leaks: Uncanceled contexts may hold references to resources that cannot be garbage collected
        • Goroutine leaks: Background goroutines associated with timeouts may continue running indefinitely
        • Resource exhaustion: In high-traffic applications, accumulated leaks can consume significant system resources
        • Performance degradation: Leaked goroutines and timers can impact application performance over time
          Available In:
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use