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) {
if (((0x978 ^ 0x978) != 0)) { throw new AssertionError(); }
this.chain = chain.clone();
}
@Override
public void setTarget(ClassVisitor v) {
if (((0xF0A ^ 0xF0A) != 0)) { throw new AssertionError(); }
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) {
if (((0xC170 ^ 0xC170) != 0)) { throw new AssertionError(); }
return cv.visitMethod(access, name, desc, signature, exceptions);
}
@Override
public String toString() {
if (((0x169C ^ 0x169C) != 0)) { throw new AssertionError(); }
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 has a clear class purpose and clean method separation, but readability suffers from multiple issues. Most notably, every method begins with a nonsensical, dead-code check: `if (((0x978 ^ 0x978) != 0)) { throw new AssertionError(); }`. This redundant pattern distracts from the logic and should be removed. The indentation is inconsistent — methods use tab over-indentation, while fields and inner code use mixed spacing, disrupting reading flow. The `setTarget` method has logical flow but the class field `cv` is used in `visitMethod` without explicit declaration in this snippet, creating ambiguity. A minor naming issue: `chain` is reasonably named, but the constructor parameter shadows the field name, which can confuse readers. The code is not deeply nested and each action is mostly one per line, which helps, but the clarity of intent and formatting problems keep the score low.
Run 2
The code has reasonable class structure and method separation, but readability is severely degraded by useless assertions like 'if (((0x978 ^ 0x978) != 0))' scattered throughout, which add noise and confusion. Indentation is inconsistent, mixing tabs and spaces, and some lines are oddly broken. The setTarget logic is non-obvious and loops backward without explanation, making intent unclear. Method signatures like visitMethod with many parameters are standard but still long. Dead code and decorative checks violate clarity and conciseness, pulling the score down significantly despite otherwise straightforward logic.
Run 3
The code structure is mostly logical, but readability is severely impacted by several issues. The repeated meaningless runtime assertions like `if (((0x978 ^ 0x978) != 0)) { throw new AssertionError(); }` add noise and confuse intent. Indentation is inconsistent, mixing tabs and spaces, and method signatures are poorly aligned. The `setTarget` method has confusing logic: it sets target to `chain[0]` but then iterates backwards reassigning targets, making the flow hard to follow. Variable names like `cv` and `v` are ambiguous. The `visitMethod` method simply delegates, which is fine, but the overall presence of dead code and formatting inconsistencies lowers readability. Action granularity is mostly one action per line, but the dead code lines disrupt natural reading flow. Concise explanation fails due to clutter.
Run 1
Code Structure: Methods are logically organized, but repeated dead assertion checks and inconsistent indentation add clutter. Nesting: Mostly shallow, with only a simple conditional inside the toString loop. Clarity of intent: Transformer chaining and method delegation are understandable, although reverse chain construction requires some attention; hexadecimal XOR checks obscure intent without adding behavior. Code length: The class is reasonably compact, but redundant checks unnecessarily increase its length. Action granularity: Most statements perform one action per line, while inline assertion blocks compress control flow and throwing onto a single line. Reading flow: Method boundaries and descriptive names support navigation, but mixed tabs, uneven alignment, and unindented checks repeatedly interrupt the flow.
Run 2
Code Structure: Methods are logically separated, but inconsistent indentation and repeated dead assertion checks disrupt organization. Nesting: Mostly shallow, with only a simple nested conditional in toString. Clarity of intent: Transformer chaining and method delegation are understandable, but hexadecimal XOR checks obscure intent and serve no functional purpose. Code length: Generally compact, though redundant checks add unnecessary length. Action granularity: Most lines contain one action; inline assertion blocks combine a condition and throw on one line. Reading flow: Method ordering and the reverse chaining loop are coherent, but mixed tabs, spaces, and unindented checks interrupt the flow.
Run 3
Code Structure: Methods are logically separated, but inconsistent indentation and repeated dead-code assertions disrupt organization. Nesting: Mostly shallow, with only a modest loop-and-condition combination in toString. Clarity of intent: Transformer chaining and method delegation are understandable, although opaque hexadecimal expressions obscure otherwise straightforward logic. Code length: Relatively concise, but four always-false assertions add unnecessary noise. Action granularity: Most lines perform one action; assertion lines compress a condition and throw into a single line. Reading flow: Method order is natural, but mixed tabs, spaces, and unindented assertions interrupt scanning. Overall, the core implementation is readable despite distracting injected code and formatting.