Using _ (underscore) as Variable Name in Java

Using underscores (_) as variable names in Java has been a topic of discussion among developers, primarily due to its evolution in Java language conventions and its implications on readability, convention adherence, and best practices. Here's a detailed exploration of using underscores as variable names in Java.

Evolution and History

In earlier versions of Java, underscores were not allowed in variable names. Java syntax strictly limited variable names to alphanumeric characters and underscores were reserved for specific use cases like separating words in constant names (MAX_VALUE, MIN_VALUE). However, with the introduction of Java SE 7, underscores gained new significance with the introduction of the underscore character (_) as a valid identifier in certain contexts.

Legal Uses of Underscore in Java

Identifiers in Java SE 7 and Later: Since Java SE 7, underscores can be used as identifiers in certain contexts:

  • Variable Names: Allowed as variable names (int _myVar;).
  • Method Names: Can be part of method names (void my_method() { ... }).
  • Class Names: Allowed as class names (class MyClass_ { ... }).
  • Package Names: Not recommended (package com.example._;).
  • Import Statements: Not recommended (import com.example._;).

Naming Conventions and Best Practices:

  • CamelCase vs. Underscores: Java convention typically uses CamelCase for variables (myVariableName) and underscores for constants (MAX_VALUE). Using underscores for variables can diverge from this convention but is legal.
  • Readability Considerations: While legal, excessive use of underscores in variable names can reduce code readability, as it might not align with standard Java naming conventions.

Restrictions Introduced in Java 9

Starting with Java 9, a significant change was introduced: the use of a single underscore (_) as an identifier was disallowed. This change was part of the language's evolution to prevent potential confusion and improve code readability. The change was formalized in JEP 213: Milling Project Coin that includes several small language changes and updates.

Here's what happens if we try to use _ as a variable name in Java 9 or later:

The compiler error would look something like this:

Why Was This Change Made?

The decision to make _ a keyword in Java 9 was influenced by a few factors:

Readability: A single underscore as a variable name is not descriptive and can make code harder to understand and maintain.

Future Language Features: Reserving _ as a keyword leaves room for potential future language features that might benefit from having a dedicated symbol.

Consistency with Other Languages: Some other programming languages also discourage or disallow the use of _ as an identifier. Aligning Java with these practices can reduce confusion for developers who work with multiple languages.

Allowed Usage of Underscores

While using a single underscore is prohibited, underscores can still be part of variable names in combination with other characters:

File Name: UnderscoreExample.java

Output:

 
User ID: 101
User Name: Alice   

Practical Considerations

Compatibility and Maintenance:

  • Legacy Code: Older Java codebases might not utilize underscores due to earlier Java versions.
  • Team Consistency: Maintaining consistency within a development team is crucial. Agreeing on naming conventions ensures readability and maintainability.

Compiler and IDE Support:

  • Syntax Highlighting: Modern IDEs support underscores in identifiers, providing syntax highlighting and error checking.
  • Code Review: Including underscore usage in code review processes helps enforce best practices and maintain readability standards.

Conclusion

Using underscores as variable names in Java is legally permissible since Java SE 7, although it deviates from traditional naming conventions. While it offers flexibility in naming, adherence to established standards, such as CamelCase, significantly enhances code readability and maintainability.

Developers should carefully balance the advantages of using underscores with the crucial need for clear, understandable code, ensuring that consistent team-wide conventions are followed to maintain codebase integrity, cohesiveness, and overall readability across the project.