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: 45 rules found
convention
    Impact
      Clean code attribute
        1. Literal suffixes should be upper case

           Code Smell
        2. Local constants should follow naming conventions for constants

           Code Smell
        3. Test methods should comply with a naming convention

           Code Smell
        4. Test classes should comply with a naming convention

           Code Smell
        5. Fields should not be initialized to default values

           Code Smell
        6. Static non-final field names should comply with a naming convention

           Code Smell
        7. Unnecessary semicolons should be omitted

           Code Smell
        8. Types should be used in lambdas

           Code Smell
        9. Classes named like "Exception" should extend "Exception" or a subclass

           Code Smell
        10. "Cloneables" should implement "clone"

           Code Smell
        11. Underscores should be used to make large numbers readable

           Code Smell
        12. The names of methods with boolean return values should start with "is" or "has"

           Code Smell
        13. An abstract class should have both abstract and concrete methods

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

           Code Smell
        15. Track lack of copyright and license headers

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

           Code Smell
        17. Loggers should be "private static final" and should share a naming convention

           Code Smell
        18. Packages should have a javadoc file 'package-info.java'

           Code Smell
        19. The default unnamed package should not be used

           Code Smell
        20. Statements should be on separate lines

           Code Smell
        21. The members of an interface or class declaration should appear in a pre-defined order

           Code Smell
        22. Package names should comply with a naming convention

           Code Smell
        23. Array designators "[]" should be on the type, not the variable

           Code Smell
        24. Array designators "[]" should be located after the type in method signatures

           Code Smell
        25. Type parameter names should comply with a naming convention

           Code Smell
        26. Classes that override "clone" should be "Cloneable" and call "super.clone()"

           Code Smell
        27. Abstract class names should comply with a naming convention

           Code Smell
        28. Public types, methods and fields (API) should be documented with Javadoc

           Code Smell
        29. Public constants and fields initialized at declaration should be "static final" rather than merely "final"

           Code Smell
        30. Local variable and method parameter names should comply with a naming convention

           Code Smell
        31. Field names should comply with a naming convention

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

           Code Smell
        33. Interface names should comply with a naming convention

           Code Smell
        34. Files should end with a newline

           Code Smell
        35. Modifiers should be declared in the correct order

           Code Smell
        36. Source code should be indented consistently

           Code Smell
        37. A close curly brace should be located at the beginning of a line

           Code Smell
        38. Close curly brace and the next "else", "catch" and "finally" keywords should be on two different lines

           Code Smell
        39. Close curly brace and the next "else", "catch" and "finally" keywords should be located on the same line

           Code Smell
        40. An open curly brace should be located at the beginning of a line

           Code Smell
        41. An open curly brace should be located at the end of a line

           Code Smell
        42. Tabulation characters should not be used

           Code Smell
        43. Lines should not be too long

           Code Smell
        44. Class names should comply with a naming convention

           Code Smell
        45. Method names should comply with a naming convention

           Code Smell

        Local variable and method parameter names should comply with a naming convention

        consistency - identifiable
        maintainability
        Code Smell
        • convention

        Local variables and method parameters should be named consistently to communicate intent and improve maintainability. Rename your local variable or method parameter to follow your project’s naming convention to address this issue.

        Why is this an issue?

        How can I fix it?

        More Info

        A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
        Local variables and method parameters hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern.
        Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.

        This rule checks that local variable and method parameter names match a provided regular expression.

        What is the potential impact?

        Inconsistent naming of local variables and method parameters can lead to several issues in your code:

        • Reduced Readability: Inconsistent local variable and method parameter names make the code harder to read and understand; consequently, it is more difficult to identify the purpose of each variable, spot errors, or comprehend the logic.
        • Difficulty in Identifying Variables: The local variables and method parameters that don’t adhere to a standard naming convention are challenging to identify; thus, the coding process slows down, especially when dealing with a large codebase.
        • Increased Risk of Errors: Inconsistent or unclear local variable and method parameter names lead to misunderstandings about what the variable represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code.
        • Collaboration Difficulties: In a team setting, inconsistent naming conventions lead to confusion and miscommunication among team members.
        • Difficulty in Code Maintenance: Inconsistent naming leads to an inconsistent codebase. The code is difficult to understand, and making changes feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain.

        In summary, not adhering to a naming convention for local variables and method parameters can lead to confusion, errors, and inefficiencies, making the code harder to read, understand, and maintain.

        Exceptions

        Loop counters are ignored by this rule.

        for (int i_1 = 0; i_1 < limit; i_1++) {  // Compliant
          // ...
        }
        

        as well as one-character catch variables:

        try {
        //...
        } catch (Exception e) { // Compliant
        }
        
          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