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
 
Tags
    Impact
      Clean code attribute
        1. File existence checks followed by file creation should use atomic operations

           Vulnerability
        2. Busy waiting loops should use proper synchronization

           Bug
        3. Context should not be stored in struct fields

           Code Smell
        4. Context parameters should be reused instead of creating new background contexts

           Code Smell
        5. Package imports should be consistent and avoid redundancy

           Code Smell
        6. Variables should be used

           Code Smell
        7. Consecutive function parameters with the same type should be grouped

           Code Smell
        8. HTTP response bodies should be closed to prevent resource leaks

           Bug
        9. Deprecated "InterfaceData" method should not be used

           Bug
        10. Named types should be used instead of anonymous structs for complex nested structures

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

           Code Smell
        12. Single-method interface names should follow Go naming conventions

           Code Smell
        13. Variables in if short statements should be used beyond just the condition

           Code Smell
        14. Context cancellation functions should be deferred

           Code Smell
        15. Blank imports should be documented to explain their purpose

           Code Smell
        16. Function and method names should not use "Get" prefix

           Code Smell
        17. Custom error types must implement "Error()" method correctly

           Bug
        18. Semicolons should not be used unnecessarily

           Code Smell
        19. Database transactions should be properly handled with rollback mechanisms

           Bug
        20. Test functions should not call "t.Fatal" from separate goroutines

           Bug
        21. Import statements should be factored into a single block

           Code Smell
        22. Functions should follow Go's explicit error handling patterns

           Code Smell
        23. Credentials should not be hard-coded

           Vulnerability
        24. Hard-coded secrets are security-sensitive

           Security Hotspot
        25. Constructing arguments of system commands from user input is security-sensitive

           Security Hotspot
        26. Extracting archives should not lead to zip slip vulnerabilities

           Vulnerability
        27. JWT should be signed and verified with strong cipher algorithms

           Vulnerability
        28. Cipher algorithms should be robust

           Vulnerability
        29. Encryption algorithms should be used with secure mode and padding scheme

           Vulnerability
        30. Server hostnames should be verified during SSL/TLS connections

           Vulnerability
        31. Insecure temporary file creation methods should not be used

           Vulnerability
        32. Using publicly writable directories is security-sensitive

           Security Hotspot
        33. Passwords should not be stored in plaintext or with a fast hashing algorithm

           Vulnerability
        34. Using clear-text protocols is security-sensitive

           Security Hotspot
        35. HTTP request redirections should not be open to forging attacks

           Vulnerability
        36. Logging should not be vulnerable to injection attacks

           Vulnerability
        37. Server-side requests should not be vulnerable to forging attacks

           Vulnerability
        38. Server certificates should be verified during SSL/TLS connections

           Vulnerability
        39. Using weak hashing algorithms is security-sensitive

           Security Hotspot
        40. Multi-line comments should not be empty

           Code Smell
        41. Delivering code in production with debug features activated is security-sensitive

           Security Hotspot
        42. Cryptographic keys should be robust

           Vulnerability
        43. Weak SSL/TLS protocols should not be used

           Vulnerability
        44. Functions should not have identical implementations

           Code Smell
        45. Searching OS commands in PATH is security-sensitive

           Security Hotspot
        46. All branches in a conditional structure should not have exactly the same implementation

           Bug
        47. Cognitive Complexity of functions should not be too high

           Code Smell
        48. Database queries should not be vulnerable to injection attacks

           Vulnerability
        49. Creating cookies without the "HttpOnly" flag is security-sensitive

           Security Hotspot
        50. Cipher Block Chaining IVs should be unpredictable

           Vulnerability
        51. Non-existent operators like "=+" should not be used

           Bug
        52. Setting loose POSIX file permissions is security-sensitive

           Security Hotspot
        53. Go parser failure

           Code Smell
        54. Using pseudorandom number generators (PRNGs) is security-sensitive

           Security Hotspot
        55. Creating cookies without the "secure" flag is security-sensitive

           Security Hotspot
        56. XPath expressions should not be vulnerable to injection attacks

           Vulnerability
        57. I/O function calls should not be vulnerable to path injection attacks

           Vulnerability
        58. Formatting SQL queries is security-sensitive

           Security Hotspot
        59. OS commands should not be vulnerable to command injection attacks

           Vulnerability
        60. Hard-coded credentials are security-sensitive

           Security Hotspot
        61. Password hashing functions should use an unpredictable salt

           Vulnerability
        62. Boolean checks should not be inverted

           Code Smell
        63. Two branches in a conditional structure should not have exactly the same implementation

           Code Smell
        64. Related "if/else if" statements should not have the same condition

           Bug
        65. "switch" statements should not be nested

           Code Smell
        66. Identical expressions should not be used on both sides of a binary operator

           Bug
        67. All code should be reachable

           Bug
        68. Variables should not be self-assigned

           Bug
        69. "switch" statements should not have too many "case" clauses

           Code Smell
        70. Track lack of copyright and license headers

           Code Smell
        71. Functions and methods should not have too many lines

           Code Smell
        72. Control flow statements "if", "for" and "switch" should not be nested too deeply

           Code Smell
        73. Octal values should not be used

           Code Smell
        74. Using hardcoded IP addresses is security-sensitive

           Security Hotspot
        75. "switch" statements should have "default" clauses

           Code Smell
        76. "if ... else if" constructs should end with "else" clauses

           Code Smell
        77. Statements should be on separate lines

           Code Smell
        78. String literals should not be duplicated

           Code Smell
        79. Functions should not be empty

           Code Smell
        80. Unused function parameters should be removed

           Code Smell
        81. Local variable and function parameter names should comply with a naming convention

           Code Smell
        82. "switch case" clauses should not have too many lines

           Code Smell
        83. Useless "if(true) {...}" and "if(false){...}" blocks should be removed

           Bug
        84. Track uses of "TODO" tags

           Code Smell
        85. Track uses of "FIXME" tags

           Code Smell
        86. Boolean literals should not be redundant

           Code Smell
        87. Empty statements should be removed

           Code Smell
        88. Redundant pairs of parentheses should be removed

           Code Smell
        89. Nested blocks of code should not be left empty

           Code Smell
        90. Functions should not have too many parameters

           Code Smell
        91. Expressions should not be too complex

           Code Smell
        92. Files should not have too many lines of code

           Code Smell
        93. Lines should not be too long

           Code Smell
        94. Function names should comply with a naming convention

           Code Smell

        Test functions should not call "t.Fatal" from separate goroutines

        intentionality - logical
        reliability
        maintainability
        Bug
        • testing
        • concurrency

        This rule raises an issue when test functions call t.Fatal, t.FailNow, t.Fatalf, t.Skip, t.Skipf, or t.SkipNow from goroutines other than the main test goroutine.

        Why is this an issue?

        How can I fix it?

        More Info

        In Go testing, functions like t.Fatal and t.FailNow call runtime.Goexit() to immediately terminate the current goroutine and mark the test as failed. However, when these functions are called from a goroutine other than the main test goroutine, they only terminate that specific goroutine, not the entire test.

        This creates several problems:

        • The test may continue running even after a failure is detected, leading to unpredictable behavior
        • Other goroutines may continue executing, potentially causing resource leaks or interfering with subsequent tests
        • The test may hang indefinitely if the main goroutine is waiting for the failed goroutine to complete
        • Error reporting becomes unclear since the test doesn’t immediately fail when the issue is detected

        The Go testing package is designed with the assumption that test control functions are called from the main test goroutine. When this assumption is violated, the testing framework cannot properly manage the test lifecycle.

        What is the potential impact?

        Calling t.Fatal from separate goroutines can cause tests to hang indefinitely, produce unreliable results, or mask real failures. This leads to flaky tests that are difficult to debug and can block continuous integration pipelines. In severe cases, hanging tests may consume system resources and require manual intervention to terminate.

          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