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: 21 rules found
brain-overload
    Impact
      Clean code attribute
        1. Cognitive Complexity of methods should not be too high

           Code Smell
        2. Classes should not have too many "static" imports

           Code Smell
        3. Inner classes should not have too many lines of code

           Code Smell
        4. Files should contain only one top-level class or interface each

           Code Smell
        5. Variables should not be declared before they are relevant

           Code Smell
        6. Classes should not have too many fields

           Code Smell
        7. The ternary operator should not be used

           Code Smell
        8. A field should not duplicate the name of its containing class

           Code Smell
        9. Methods should not be too complex

           Code Smell
        10. "switch" statements should not have too many "case" clauses

           Code Smell
        11. Classes should not have too many methods

           Code Smell
        12. Methods should not have too many lines

           Code Smell
        13. Loops should not contain more than a single "break" or "continue" statement

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

           Code Smell
        15. Classes should not be coupled to too many other classes

           Code Smell
        16. "switch case" clauses should not have too many lines of code

           Code Smell
        17. Methods should not have too many return statements

           Code Smell
        18. Magic numbers should not be used

           Code Smell
        19. Methods should not have too many parameters

           Code Smell
        20. Expressions should not be too complex

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

           Code Smell

        Classes should not be coupled to too many other classes

        adaptability - focused
        maintainability
        Code Smell
        • architecture
        • brain-overload

        Why is this an issue?

        According to the Single Responsibility Principle, introduced by Robert C. Martin in his book "Principles of Object Oriented Design", a class should have only one responsibility:

        If a class has more than one responsibility, then the responsibilities become coupled.

        Changes to one responsibility may impair or inhibit the class' ability to meet the others.

        This kind of coupling leads to fragile designs that break in unexpected ways when changed.

        Classes which rely on many other classes tend to aggregate too many responsibilities and should be split into several smaller ones.

        Nested classes dependencies are not counted as dependencies of the outer class.

        Noncompliant code example

        With a threshold of 5:

        class Foo {                        // Noncompliant - Foo depends on too many classes: T1, T2, T3, T4, T5, T6 and T7
          T1 a1;                           // Foo is coupled to T1
          T2 a2;                           // Foo is coupled to T2
          T3 a3;                           // Foo is coupled to T3
        
          public T4 compute(T5 a, T6 b) {  // Foo is coupled to T4, T5 and T6
            T7 result = a.getResult(b);    // Foo is coupled to T7
            return result;
          }
        
          public static class Bar {        // Compliant - Bar depends on 2 classes: T8 and T9
            T8 a8;
            T9 a9;
          }
        }
        
          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