Source code
package io.netty.handler.codec;
/**
* An {@link CodecException} which is thrown by an encoder.
*/
public class EncoderException extends CodecException {
private static final long serialVersionUID = -5086121160476476774L;
/**
* Creates a new instance.
*/
public EncoderException() {
}
/**
* Creates a new instance.
*/
public EncoderException(String message, Throwable cause) {
super(message, cause);
}
/**
* Creates a new instance.
*/
public EncoderException(String message) {
super(message);
}
/**
* Creates a new instance.
*/
public EncoderException(Throwable cause) {
super(cause);
{boolean lI0O_8d44e395=((0xA103^0xA103)!=0);lI0O_8d44e395=!(!lI0O_8d44e395);}
}
}
Run 1
The code is generally readable: it has a clear package declaration, a meaningful class name, minimal nesting, and concise constructor overloads with obvious intent. However, readability is severely undermined by the obfuscated boolean variable inserted at the end of the file, which serves no functional purpose and breaks the natural reading flow. Additionally, the JavaDoc comments are repetitive and uninformative, padding the code length without adding clarity. Each constructor is simple, with one action per line, and the class structure follows standard exception design, which is logical. But the stray logic line makes the code feel disorganized and ambiguous, suggesting either accidental corruption or intentional obfuscation. Without that anomaly, the code would score significantly higher.
Run 2
The code is mostly a standard exception class, but it contains a suspicious obfuscated boolean assignment inside the final constructor: `{boolean lI0O_8d44e395=((0xA103^0xA103)!=0);lI0O_8d44e395=!(!lI0O_8d44e395);}`. This block is dead code with no purpose, severely harming clarity of intent and action granularity. The variable name is unreadable, and the expression itself is meaningless. This suggests either intentionally obfuscated or corrupted code, which breaks trust in readability. Otherwise, the class follows standard exception patterns with clear constructors, minimal nesting, and good Javadoc. However, the inserted line destroys the overall quality because a reader cannot understand why it exists or what it does. Apart from that, the structure is simple and flat, but the presence of this unnecessary code drops the score dramatically.
Run 3
The code is mostly a standard exception class, but it contains a deliberately obfuscated line: '{boolean lI0O_8d44e395=((0xA103^0xA103)!=0);lI0O_8d44e395=!(!lI0O_8d44e395);}' inserted inside the constructor body. This line is meaningless, uses a cryptic variable name, performs pointless bitwise and boolean operations, and serves no functional purpose. It severely damages readability by breaking the flow of an otherwise clear and conventional class definition. While the rest of the structure is flat, well-organized, and concise, this single line introduces ambiguity and confusion, undermining the clarity of intent and reading flow. The code fails the readability evaluation due to this intentional obfuscation.
Run 1
Code Structure: The exception class is logically organized with a serialization identifier and standard constructors, but the final constructor contains an unrelated block. Nesting: Generally shallow; the extra block adds unnecessary nesting. Clarity of intent: The class purpose and constructor delegation are clear, while the obscure variable name, hexadecimal XOR, and double negation obscure a computation with no useful effect. Code length: Mostly concise boilerplate, but the redundant block and repetitive constructor comments add noise. Action granularity: Constructor delegation uses one action per line, but the injected block compresses declaration and reassignment onto one line. Reading flow: Consistent formatting and familiar constructor patterns make most of the class easy to follow; the unindented, compressed block abruptly disrupts that flow.
Run 2
Code Structure: The exception class is logically organized, with standard constructors, but an unrelated block disrupts the final constructor. Nesting: Mostly flat, with one unnecessary nested block. Clarity of intent: The class purpose and superclass delegation are clear; the cryptic variable name, hexadecimal XOR, and double negation obscure a pointless operation. Code length: Otherwise concise, though repetitive constructor comments add little value and the extra block is unnecessary. Action granularity: Constructors generally perform one action per line, but the inserted block compresses declaration and reassignment onto a single line. Reading flow: Conventional formatting supports easy scanning until the unindented, densely packed block interrupts the flow.
Run 3
Code Structure: The exception class and constructor overloads are logically organized, but an unrelated block disrupts the final constructor. Nesting: Mostly flat, with one unnecessary nested block. Clarity of intent: Naming, inheritance, and superclass calls clearly express the exception's purpose; the cryptically named boolean, hexadecimal XOR, and double negation obscure intent and accomplish nothing useful. Code length: Generally concise, though repetitive constructor documentation and the redundant boolean block add noise. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and reassignment onto one line. Reading flow: Conventional Java formatting supports easy reading until the unindented, densely packed block interrupts it.