Source code
package org.springframework.expression.spel.ast;
import org.springframework.asm.MethodVisitor;
import org.springframework.expression.TypedValue; import org.springframework.expression.spel.CodeFlow;
/**
* Expression language AST node that represents a long integer literal.
*
* @author Andy Clement
* @since 3.0
*/
public class LongLiteral extends Literal { private final TypedValue value;
public LongLiteral(String payload, int startPos, int endPos, long value) {
super(payload, startPos, endPos);
this.value = new TypedValue(value);
this.exitTypeDescriptor = "J"; } @Override
public TypedValue getLiteralValue() {
return this.value;
} @Override public boolean isCompilable() {
return true;
} @Override
public void generateCode(MethodVisitor mv, CodeFlow cf) {
mv.visitLdcInsn(this.value.getValue()); cf.pushDescriptor(this.exitTypeDescriptor); } }
Run 1
The code has severe readability problems. The structure is tangled, with multiple classes and import statements on single lines, and method declarations and closing braces crammed together (e.g., '} @Override public boolean isCompilable()'). There is no consistent indentation or line breaks—the class declaration immediately follows the imports, and fields are aligned with methods. Nesting is minimal but the lack of whitespace makes logical grouping unclear. Clarity of intent is obscured by the compressed formatting; the actual purpose of the class is unclear until one deciphers the method names. The code length is short but unnaturally so, sacrificing readability for compactness. Action granularity is poor—multiple actions (closing brace, annotation, method signature, opening brace) occur on single lines. Reading flow is disorganized, forcing the reader to constantly reparse lines to separate elements. The code would be much clearer with standard line breaks, indentation, and spacing between methods and fields. The content is simple, but presentation destroys readability.
Run 2
The code is a simple AST node but suffers from poor formatting that hurts readability. The structure mixes multiple statements on single lines, inconsistent indentation, and method declarations placed on the same line as closing braces. While the overall purpose is fairly clear (representing a long literal), the execution lacks clean separation between class members. Nesting is not an issue, but action granularity is poor—several actions are packed onto single lines. The reading flow is disrupted by cramped code and inconsistent spacing. Concise in length, yes, but this compactness is achieved at the cost of clarity and conventional formatting. Improved line breaks and indentation would make this much more readable.
Run 3
The code is poorly structured and difficult to read. Multiple statements are compressed onto single lines, mixing field declarations, constructor logic, and method definitions with inconsistent indentation and brace placement. This violates action granularity and disrupts natural reading flow. While the class has a clear purpose and the methods are functionally simple, the formatting obscures the logical organization. The import statements are also combined on one line, and closing braces are crammed together. Restructuring into properly indented, one-action-per-line code would greatly improve readability.
Run 1
Code Structure: The class logically groups a literal's value, constructor, and overrides, but compressed formatting obscures method boundaries. Nesting: Very shallow, with no conditional or loop nesting. Clarity of intent: The class documentation, descriptive names, and straightforward methods clearly convey its purpose; the descriptor "J" requires JVM knowledge. Code length: Concise, with no unnecessary logic, though excessive compression hurts readability. Action granularity: Multiple imports and statements share lines, and braces and annotations run into subsequent declarations. Reading flow: The method order is natural, but inconsistent spacing and line breaks force readers to disentangle otherwise simple code.
Run 2
Code Structure: The class logically groups its field, constructor, and methods, but compressed formatting obscures these boundaries. Nesting: Minimal nesting makes the implementation easy to follow. Clarity of intent: The documentation, class name, and method names clearly identify a long-literal AST node and its behavior. Code length: The implementation is appropriately concise, with no unnecessary logic. Action granularity: Multiple imports, declarations, annotations, and statements share lines, reducing visual separation; generateCode places two actions on one line. Reading flow: Inconsistent spacing and closing braces merged with subsequent annotations interrupt otherwise straightforward top-to-bottom reading. Conventional formatting would substantially improve readability without changing the implementation.
Run 3
Code Structure: The class logically groups its field, constructor, and overridden methods, but compressed declarations and inconsistent formatting obscure boundaries. Nesting: Minimal nesting keeps the implementation easy to follow. Clarity of intent: The documentation, class name, and method names clearly identify a long-literal AST node; the descriptor "J" requires JVM knowledge. Code length: The implementation is concise without unnecessary logic, although excessive line compression reduces readability. Action granularity: Multiple imports, statements, annotations, and closing braces share lines, making individual operations harder to distinguish. Reading flow: The overall sequence is natural, but irregular whitespace and annotations attached to preceding closing braces interrupt scanning.