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
Java

Java static code analysis

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

  • All rules 733
  • Vulnerability60
  • Bug175
  • Security Hotspot40
  • Code Smell458

  • Quick Fix 65
Filtered: 26 rules found
confusing
    Impact
      Clean code attribute
        1. Tests should use fixed data instead of randomized data

           Code Smell
        2. "else" statements should be clearly matched with an "if"

           Code Smell
        3. Methods should not have identical implementations

           Code Smell
        4. Collection sizes and array length comparisons should make sense

           Bug
        5. A conditionally executed single line should be denoted by indentation

           Code Smell
        6. Format strings should be used correctly

           Code Smell
        7. Loggers should be named for their enclosing classes

           Code Smell
        8. Methods should not return constants

           Code Smell
        9. "private" methods called only by inner classes should be moved to those classes

           Code Smell
        10. Ternary operators should not be nested

           Code Smell
        11. "static" base class members should not be accessed via derived types

           Code Smell
        12. "writeObject" should not be the only "synchronized" code in a class

           Code Smell
        13. Abstract methods should not be redundant

           Code Smell
        14. Escaped Unicode characters should not be used

           Code Smell
        15. "readObject" should not be "synchronized"

           Code Smell
        16. Child class fields should not shadow parent class fields

           Code Smell
        17. TestCases should contain tests

           Code Smell
        18. "final" classes should not have "protected" members

           Code Smell
        19. "for" loop increment clauses should modify the loops' counters

           Code Smell
        20. Simple class names should be used

           Code Smell
        21. Methods and field names should not be the same or differ only by capitalization

           Code Smell
        22. Loops with at most one iteration should be refactored

           Bug
        23. JUnit4 @Ignored and JUnit5 @Disabled annotations should be used to disable tests and should provide a rationale

           Code Smell
        24. Try-catch blocks should not be nested

           Code Smell
        25. Labels should not be used

           Code Smell
        26. Redundant pairs of parentheses should be removed

           Code Smell

        Format strings should be used correctly

        intentionality - logical
        maintainability
        Code Smell
        • cert
        • confusing

        Why is this an issue?

        How can I fix it?

        More Info

        A printf--style format string is a string that contains placeholders, usually represented by special characters such as "%s" or "{}", depending on the technology in use. These placeholders are replaced by values when the string is printed or logged.

        Because printf-style format strings are interpreted at runtime, rather than validated by the compiler, they can contain errors that result in the wrong strings being created.

        This rule checks whether every format string specifier can be correctly matched with one of the additional arguments when calling the following methods:

        • java.lang.String#format
        • java.util.Formatter#format
        • java.io.PrintStream#format
        • java.text.MessageFormat#format
        • java.io.PrintWriter#format
        • java.io.PrintStream#printf
        • java.io.PrintWriter#printf
        • java.lang.String#formatted (since Java 15)
        • logging methods of org.slf4j.Logger, java.util.logging.Logger, org.apache.logging.log4j.Logger.
          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 Community BuildAnalyze code in your
          on-premise CI
          Available Since
          9.1
        • 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