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 code is generally readable but has several issues. Structure is logical with clear class purpose, but there's inconsistent indentation (tabs vs spaces) in method declarations. Nesting is minimal and acceptable. Intent is mostly clear, though the setTarget logic with reverse iteration is somewhat confusing - it iterates backwards while building the chain forward, requiring careful reading to understand. Code length is appropriate for the functionality. Action granularity is mixed - most lines handle one action, but the loop in setTarget combines assignment and traversal. Reading flow is disrupted by inconsistent formatting and the non-intuitive reverse loop. The visitMethod override is trivial but adds little value. Overall, the code conveys its purpose but could benefit from better formatting consistency and possibly a comment explaining the reverse iteration logic in setTarget.
Run 2
The code is generally clear and concise. The class has a single responsibility: chaining class transformers. The constructor defensively clones the input array. The `setTarget` method uses a straightforward reverse loop to build the chain, though its logic could benefit from a brief comment explaining the reverse iteration. `visitMethod` is a simple delegation. `toString` is readable but slightly verbose; it could use `String.join` for simplicity. Minor formatting inconsistencies exist, such as mixed indentation (tabs vs spaces) and inconsistent opening brace placement in `toString`. Overall, the structure is logical, nesting is shallow, and intent is mostly clear, making the code highly readable with only small style improvements possible.
Run 3
The code is generally readable with clear class and method names. The structure is logical, and the setTarget method shows a reasonable approach to chaining transformers. Nesting is minimal, and actions are mostly one per line. However, there are some readability issues: inconsistent indentation (mixing tabs and spaces), the setTarget loop iterates in reverse with non-obvious variable name 'next' that could be clearer, and the toString method could be more concise. The visitMethod override seems redundant as it just delegates to the parent class's visitor. Overall, the code is understandable but has minor formatting and clarity issues that prevent it from being highly readable.
Run 1
Code Structure: The class is logically organized into construction, target wiring, method delegation, and string representation. Nesting: Control flow is shallow, with only a simple conditional inside one loop. Clarity of intent: Names generally communicate purpose, though reverse-order chain wiring requires some interpretation and names like v, cv, and sb are terse. Code length: The implementation is concise; explicit string-building adds modest verbosity without obscuring behavior. Action granularity: Each statement performs a single clear action. Reading flow: Methods follow a natural order, but mixed tabs and spaces, uneven parameter alignment, and minimal spacing around the package/import section reduce visual consistency.
Run 2
Code Structure: The class is logically organized into construction, target wiring, method delegation, and string representation. Nesting: Shallow overall, with only a loop containing a conditional in toString. Clarity of intent: Class and method names communicate their purpose, though reverse chain wiring requires some thought, and names such as v, cv, and sb are less descriptive. Code length: Compact, with little unnecessary code; string formatting could be simplified slightly. Action granularity: Each statement performs a distinct action, making execution easy to follow. Reading flow: Method ordering is natural, but inconsistent tab/space indentation and uneven parameter alignment interrupt visual consistency. The nonempty-chain assumption is implicit, which slightly reduces clarity.
Run 3
Code Structure: The class is logically organized into construction, target wiring, method delegation, and string representation. Nesting: Mostly flat, with only a shallow loop and conditional in toString. Clarity of intent: Class and method names communicate the transformer-chain purpose, though reverse-order wiring requires some thought and names such as v, cv, and sb are terse. Code length: Concise overall; the explicit string-building loop is slightly verbose but easy to follow. Action granularity: Each statement performs a single clear action, with no compressed multi-action lines. Reading flow: Methods follow a natural sequence, but inconsistent tab/space indentation and uneven parameter alignment reduce visual polish. The implicit requirement that the chain be nonempty is not documented.