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 a, int b, int c, long d) {
super(a, b, c);
this.value = new TypedValue(d);
this.exitTypeDescriptor = "J";
}
@Override
public TypedValue a() {
return this.value;
}
@Override
public boolean b() {
return true;
}
@Override
public void c(MethodVisitor e, CodeFlow f) {
e.visitLdcInsn(this.value.getValue());
f.pushDescriptor(this.exitTypeDescriptor);
}
}
Run 1
The code is structurally sound with logical organization, low nesting, and concise methods. However, readability is significantly hampered by poor naming conventions. Method names like a(), b(), c() and parameters a, b, c, d obscure intent, making the code hard to follow without external context. The class itself follows a clear pattern (AST node for a long literal) but the obfuscated names create unnecessary cognitive overhead. Action granularity is appropriate, with one main operation per line. Reading flow is natural due to the simple structure, but the lack of descriptive naming reduces clarity and would likely hinder maintenance or review.
Run 2
The code is functionally minimal but severely obfuscated by meaningless method and parameter names (a, b, c, d, e, f). This makes the intent of each method unclear, violating the clarity of intent and reading flow criteria. While the class structure is simple and flat, the poor naming forces the reader to infer behavior from context. The use of single-letter variables throughout destroys action granularity and natural reading flow, making the code nearly unreadable despite its short length.
Run 3
The code is logically structured but suffers from poor readability due to meaningless method and parameter names (a, b, c, d, e, f) which obscure intent. The nesting is flat and actions are mostly one per line, aiding flow, but the obfuscated identifiers force the reader to infer behavior from context. The class purpose is clear from the class name and comments, but method names like 'a()' and 'c()' break clarity. Code length is concise, though not at the cost of clarity. The reading flow is disrupted by having to map cryptic names back to their roles.
Run 1
Code Structure: The class is logically organized into a field, constructor, and overridden methods. Nesting: There is no nested control flow, making it easy to scan. Clarity of intent: The class name and documentation clearly identify a long-literal AST node, but single-letter method and parameter names obscure method purposes and argument meanings. The descriptor "J" also requires JVM-specific knowledge. Code length: The implementation is concise with little unnecessary code. Action granularity: Each statement occupies its own line and performs a distinct operation. Reading flow: The field-to-constructor-to-method sequence is natural, though ambiguous names force readers to consult superclass definitions or surrounding code.
Run 2
Code Structure: The class is logically organized into a field, constructor, and short overridden methods. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class name and documentation clearly identify a long-literal AST node, but single-letter method and parameter names obscure individual operations and roles. The JVM descriptor "J" requires domain knowledge. Code length: The implementation is concise with no unnecessary logic, though extra blank lines add minor visual spacing. Action granularity: Each statement performs one action on its own line. Reading flow: The field-to-constructor-to-method sequence is natural, and formatting is consistent; however, readers must infer the purposes of a(), b(), and c() from their bodies or superclass contract.
Run 3
Code Structure: The class is logically organized into a field, constructor, and small overridden methods. Nesting: There is no nested control flow, making it easy to scan. Clarity of intent: The class name and documentation clearly identify a long-literal AST node, but single-letter method and parameter names obscure individual responsibilities and argument meanings. The JVM descriptor "J" also requires domain knowledge. Code length: The implementation is concise with little unnecessary code, although some blank lines are excessive. Action granularity: Each statement performs one distinct action, with no compound lines. Reading flow: The field-to-constructor-to-method progression is natural, but understanding the overridden methods requires consulting the superclass because their names convey no intent.