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 profile, int schedule, int config, long token) {
super(profile, schedule, config);
this.value = new TypedValue(token);
this.exitTypeDescriptor = "J";
}
@Override
public TypedValue validateRequest() {
return this.value;
}
@Override
public boolean refreshBatch() {
return true;
}
@Override
public void buildMessage(MethodVisitor age, CodeFlow key) {
age.visitLdcInsn(this.value.getValue());
key.pushDescriptor(this.exitTypeDescriptor);
}
}
Run 1
The code is generally clear and follows standard Java conventions, but it has significant readability issues due to misleading naming. The class name 'LongLiteral' is appropriate, but methods like 'validateRequest', 'refreshBatch', and 'buildMessage' have unclear, non-descriptive names that don't reflect their actual purposes, making the code intent ambiguous. The variable names 'profile', 'schedule', 'config', 'age', and 'key' also obscure meaning. The structure is simple and flat with minimal nesting, and each method performs a single action, but the disorganized naming harms natural reading flow and clarity. The code length is concise and appropriate.
Run 2
The code is generally readable with clear structure: package/imports, class declaration, single field, constructor, and three overridden methods. Nesting is minimal and the reading flow is natural. Each method performs a single action, maintaining good action granularity. However, clarity of intent suffers due to misleading parameter names (profile, schedule, config, age, key) that don't reflect their actual roles, suggesting possible obfuscation or poor naming. The class itself is concise and not unnecessarily long. Overall, the code is well-organized and easy to follow structurally, but the unclear parameter names reduce its readability.
Run 3
The code is generally readable but has misleading method and parameter names that obscure intent. The structure is simple and flat, with clear class organization and minimal nesting, which aids readability. However, names like 'validateRequest', 'refreshBatch', 'buildMessage', and parameters like 'profile', 'schedule', 'config', 'token', 'age', and 'key' do not correspond to their actual roles, making the code ambiguous and harder to maintain. The code is concise and follows one action per line, and the reading flow is natural, but the naming issues significantly reduce clarity. Overall, it is understandable as an AST node for a long literal, but the poor naming conventions detract from its readability.
Run 1
Code Structure: The class is logically organized, with 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 names such as validateRequest, refreshBatch, buildMessage, age, and key obscure the actual operations. Constructor parameter names also provide little semantic guidance. Code length: The implementation is concise with no unnecessary logic, though extra blank lines slightly dilute presentation. Action granularity: Each statement performs a single action. Reading flow: The progression from initialization to value access and bytecode generation is natural, but misleading method and parameter names interrupt understanding. The JVM descriptor "J" requires domain knowledge.
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 misleading names such as validateRequest, refreshBatch, buildMessage, age, and key obscure the methods' actual roles. Constructor parameter names similarly lack domain meaning, and the descriptor "J" requires JVM knowledge. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one clear action on its own line. Reading flow: The progression from initialization to value access and bytecode generation is natural, though inconsistent naming interrupts comprehension.
Run 3
Code Structure: A logically organized class with one field, a constructor, and three small overridden methods. Nesting: Flat, with no nested control flow. Clarity of intent: The class name and documentation clearly identify a long literal, but method names such as validateRequest, refreshBatch, and buildMessage obscure their actual roles. Parameter names such as profile, schedule, config, age, and key are also misleading or vague. Code length: Concise, with no unnecessary implementation complexity, though extra blank lines add minor visual noise. Action granularity: Each statement performs a distinct action on its own line. Reading flow: The constructor-to-method sequence is natural and consistent, but inappropriate naming makes the behavior harder to interpret.