Source code
package org.springframework.cglib.transform; import org.springframework.asm.ClassVisitor;
import org.springframework.asm.MethodVisitor;
import org.springframework.cglib.core.ClassTransformer;
public class ClassTransformerChain extends AbstractClassTransformer {
private ClassTransformer[] chain;
public ClassTransformerChain(ClassTransformer[] chain) { this.chain = chain.clone(); } @Override
public void setTarget(ClassVisitor v) { super.setTarget(chain[0]); ClassVisitor next = v; for (int i = chain.length - 1; i >= 0; i--) {
chain[i].setTarget(next);
next = chain[i];
}
}
@Override
public MethodVisitor visitMethod(int access,
String name, String desc,
String signature,
String[] exceptions) { return cv.visitMethod(access, name, desc, signature, exceptions);
}
@Override public String toString() { StringBuilder sb = new StringBuilder();
sb.append("ClassTransformerChain{"); for (int i = 0; i < chain.length; i++) {
if (i > 0) {
sb.append(", ");
} sb.append(chain[i].toString()); }
sb.append("}"); return sb.toString();
}
}
Run 1
The class has a clear purpose but suffers from poor formatting and organization. The opening line mixes package/imports with the class declaration, and method signatures are cramped with `@Override` and modifiers on the same line. The `setTarget` method manually manages a backwards chain loop, which is harder to follow than a simple ordered iteration. The `toString` method repeats the chained-loop pattern with inline conditional logic, making it unnecessarily verbose. Nesting is shallow, which is good, but action granularity is inconsistent—some lines contain multiple statements. Overall, the code is functionally correct but visually noisy and harder to scan than necessary.
Run 2
The code suffers from poor formatting and readability. Imports and class declarations are compressed onto single lines, and method signatures mix with logic due to inconsistent line breaks. The setTarget method has confusing action granularity: variable declarations, loop control, and assignments occur on one line, reducing clarity. The loop logic is not immediately apparent due to tight packing and lack of blank lines. While the overall structure is logical (a chain of transformers), the intent is obscured by formatting. Nesting is shallow, which is a positive, but reading flow is disorganized because of uneven whitespace and abrupt line breaks. Code length is reasonable for the task, but the lack of separation between actions makes it feel longer and harder to parse. visitMethod simply delegates, but its parameter alignment is mixed. toString has clearer structure but still suffers from cramped line breaks and missing spaces around braces. Overall, the code is functional but uninviting and difficult to scan quickly.
Run 3
The code has several readability problems. Formatting is inconsistent and compressed, with multiple statements on single lines (e.g., the constructor, package declaration with import). The setTarget method contains non-obvious reversed iteration logic for building a transformer chain, making intent unclear. Naming is somewhat ambiguous (e.g., 'next', 'cv'). The toString method's loop is unnecessarily verbose and could use a join or stream. While the class is short and flat, the poor formatting, unclear action granularity, and disorganized reading flow significantly harm readability.
Run 1
Code Structure: The class is logically organized into construction, target configuration, method delegation, and string representation, but compressed formatting obscures boundaries. Nesting: Shallow overall; only a loop containing a conditional adds nesting. Clarity of intent: Class and method names communicate the transformer-chain purpose, though abbreviated variables and reverse wiring require attention. Code length: Concise, with little unnecessary code. Action granularity: Multiple imports, declarations, assignments, loops, and returns share lines, making individual actions harder to scan. Reading flow: Inconsistent indentation, crowded annotations, uneven parameter alignment, and closing braces beside statements disrupt otherwise straightforward execution flow.
Run 2
Code Structure: Fields and methods are logically organized, but compressed formatting obscures boundaries. Nesting: Shallow overall, with only a loop and conditional in toString. Clarity of intent: Class and method names communicate transformer chaining, although cv and v are terse and reverse wiring requires some attention. Code length: Compact and mostly necessary, but excessive line compression reduces readability rather than improving concision. Action granularity: Multiple declarations, statements, annotations, and braces share lines, making individual actions harder to distinguish. Reading flow: Inconsistent indentation, awkward parameter wrapping, and crowded method bodies interrupt an otherwise straightforward flow.
Run 3
Code Structure: The class is logically organized into construction, target wiring, method delegation, and string representation. Nesting: Shallow overall; only toString adds a conditional inside a loop. Clarity of intent: Class and method names communicate purpose, though abbreviated variables and reverse chain wiring require some interpretation. Code length: Concise, with little unnecessary code. Action granularity: Poor formatting places multiple statements, declarations, annotations, and braces on the same line, obscuring individual actions. Reading flow: Inconsistent indentation, compressed method bodies, and uneven parameter wrapping interrupt otherwise straightforward logic. Conventional formatting would substantially improve readability without changing the implementation.