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
VB6

VB6 static code analysis

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

  • All rules 45
  • Bug1
  • Security Hotspot1
  • Code Smell43
 
Tags
    Impact
      Clean code attribute
        1. "GoTo" statements should not be used

           Code Smell
        2. "GoSub" statements should not be used

           Code Smell
        3. "Option Explicit" should be enabled

           Code Smell
        4. Track parsing failures

           Code Smell
        5. "Select Case" statements should not be nested

           Code Smell
        6. Variable data types should be declared explicitly

           Code Smell
        7. The bang ("!") operator should not be used

           Code Smell
        8. Multiple variables should not be declared on the same line

           Code Smell
        9. Error handlers should not declare their own error handlers

           Bug
        10. "Option Base" should not be used

           Code Smell
        11. Loop invariants should not be calculated inside the loop

           Code Smell
        12. "Asc[W]" should not be called on string constants

           Code Smell
        13. "Chr[W]$()" should not be used for certain characters

           Code Smell
        14. '$' should not be used in string variable names

           Code Smell
        15. String-specific functions should be used

           Code Smell
        16. Strings should not be set to empty string

           Code Smell
        17. Strings should not be compared with empty string

           Code Smell
        18. The "&" operator should be used to concatenate strings

           Code Smell
        19. Sub and function names should comply with a naming convention

           Code Smell
        20. Subs and functions should not be too complex

           Code Smell
        21. "Select Case" statements should not have too many "Case" clauses

           Code Smell
        22. Comments should not be located at the end of lines of code

           Code Smell
        23. Subs and functions should not have too many lines

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

           Security Hotspot
        25. "Select" statements should end with a "Case Else" clause

           Code Smell
        26. "Select Case" statements should have at least 3 "Case" clauses

           Code Smell
        27. Statements should be on separate lines

           Code Smell
        28. Methods should not be empty

           Code Smell
        29. "Case" clauses should not have too many lines

           Code Smell
        30. Constant names should comply with a naming convention

           Code Smell
        31. Track uses of "TODO" tags

           Code Smell
        32. Track uses of "FIXME" tags

           Code Smell
        33. Lines should not end with trailing whitespaces

           Code Smell
        34. Return of boolean expressions should not be wrapped into an "if-then-else" statement

           Code Smell
        35. Boolean literals should not be redundant

           Code Smell
        36. Source code should be indented consistently

           Code Smell
        37. Empty statements should be removed

           Code Smell
        38. Magic numbers should not be used

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

           Code Smell
        40. Procedures should not have too many parameters

           Code Smell
        41. Unused private variables should be removed

           Code Smell
        42. Expressions should not be too complex

           Code Smell
        43. Tabulation characters should not be used

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

           Code Smell
        45. Lines should not be too long

           Code Smell

        Track uses of "TODO" tags

        intentionality - complete
        maintainability
        Code Smell
        • cwe

        Why is this an issue?

        More Info

        Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately. However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase. This description explores why this is a problem and how it can be fixed to improve the overall code quality.

        What is the potential impact?

        Unattended TODO tags in code can have significant implications for the development process and the overall codebase.

        Incomplete Functionality: When developers leave TODO tags without implementing the corresponding code, it results in incomplete functionality within the software. This can lead to unexpected behavior or missing features, adversely affecting the end-user experience.

        Missed Bug Fixes: If developers do not promptly address TODO tags, they might overlook critical bug fixes and security updates. Delayed bug fixes can result in more severe issues and increase the effort required to resolve them later.

        Impact on Collaboration: In team-based development environments, unattended TODO tags can hinder collaboration. Other team members might not be aware of the intended changes, leading to conflicts or redundant efforts in the codebase.

        Codebase Bloat: The accumulation of unattended TODO tags over time can clutter the codebase and make it difficult to distinguish between work in progress and completed code. This bloat can make it challenging to maintain an organized and efficient codebase.

        Addressing this code smell is essential to ensure a maintainable, readable, reliable codebase and promote effective collaboration among developers.

        Noncompliant code example

        Rem TODO Add documentation
        Sub DoSomething()
            ' TODO
        End Sub
        
          Available In:
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Enterprise
          Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use