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

        Methods and field names should not be the same or differ only by capitalization

        consistency - identifiable
        maintainability
        Code Smell
        • confusing

        This rule raises an issue when there is a method and a field in a class with names that differ only by capitalization.

        Why is this an issue?

        Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.

        In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.

        Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.

        Code examples

        Noncompliant code example

        public class Car{
        
          public DriveTrain drive;
        
          public void tearDown(){...}
        
          public void drive() {...}  // Noncompliant; duplicates field name
        }
        
        public class MyCar extends Car{
          public void teardown(){...}  // Noncompliant; not an override. It it really what's intended?
        
          public void drivefast(){...}
        
          public void driveFast(){...} //Huh?
        }
        

        Compliant solution

        public class Car{
        
          private DriveTrain drive;
        
          public void tearDown(){...}
        
          public void drive() {...}  // field visibility reduced
        }
        
        public class MyCar extends Car{
          @Override
          public void tearDown(){...}
        
          public void drivefast(){...}
        
          public void driveReallyFast(){...}
        
        }
        
          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