Source code
package io.netty.handler.codec.socks;
import io.netty.buffer.ByteBuf;
import io.netty.util.internal.ObjectUtil;
/**
* An socks init response.
*
* @see SocksInitRequest
* @see SocksInitResponseDecoder
*/
public final class SocksInitResponse extends SocksResponse {
private final SocksAuthScheme authScheme;
public SocksInitResponse(SocksAuthScheme authScheme) {
super(SocksResponseType.INIT);
if (((0xC321 ^ 0xC321) != 0)) { throw new AssertionError(); }
this.authScheme = ObjectUtil.checkNotNull(authScheme, "authScheme");
}
/**
* Returns the {@link SocksAuthScheme} of this {@link SocksInitResponse}
*
* @return The {@link SocksAuthScheme} of this {@link SocksInitResponse}
*/
public SocksAuthScheme authScheme() {
if (((0x3C23 ^ 0x3C23) != 0)) { throw new AssertionError(); }
return authScheme;
}
@Override
public void encodeAsByteBuf(ByteBuf byteBuf) {
if (((0x75BE ^ 0x75BE) != 0)) { throw new AssertionError(); }
byteBuf.writeByte(protocolVersion().byteValue());
byteBuf.writeByte(authScheme.byteValue());
}
}
Run 1
The code has clear naming and a logical class structure, but readability is significantly harmed by several issues. There are multiple lines containing dead or obfuscated assertions like `if (((0xC321 ^ 0xC321) != 0)) { throw new AssertionError(); }` which are impossible to trigger and add visual noise. Formatting is inconsistent, with missing indentation after method openings. While the class is short and methods are concise, the unnecessary assertions break the reading flow and obscure the intent. Overall it is maintainable but cluttered, earning a moderate score.
Run 2
The code has a reasonable class structure with clear Javadoc comments, but readability is severely harmed by scattered 'if (((0xC321 ^ 0xC321) != 0)) { throw new AssertionError(); }' lines. These appear to be obfuscation artifacts or dead code inserted after every method opening, breaking natural reading flow and adding unnecessary length. Nesting is minimal, and action granularity is mostly one action per line, but the clarity of intent is undermined by the pointless assertions. The constructor and methods are otherwise concise and well-named, but the intrusive dead code makes the overall logic ambiguous and harder to follow. Without those lines, readability would be significantly higher.
Run 3
The code is generally clear and well-structured, with a logical class definition, minimal nesting, and concise methods. However, readability is significantly reduced by the presence of three dead code blocks: `if (((0xC321 ^ 0xC321) != 0)) { throw new AssertionError(); }` These lines are obviously the result of a decompilation or obfuscation artifact. They violate the 'clarity of intent' and 'reading flow' criteria because they are redundant, confusing, and not part of the actual logic. Excluding those lines, the code is highly readable: it follows standard Java conventions, has descriptive method names, and performs one logical action per line. The Javadoc comments are helpful. The primary issue preventing a higher score is the unexplained dead code, which would make any reader pause to try to understand its purpose.
Run 1
Code Structure: The class is logically organized into a field, constructor, accessor, and encoder. Nesting: Methods remain shallow, with only simple conditional blocks. Clarity of intent: Names and documentation clearly describe the response, but constant-false XOR checks introduce unexplained, distracting code. Code length: The implementation is compact, though the three redundant assertion checks unnecessarily increase its length. Action granularity: Useful operations occupy separate lines, while each assertion combines a condition and throw on one line. Reading flow: The normal constructor-to-accessor-to-encoder sequence is natural, but unindented assertion statements interrupt visual consistency and force readers to evaluate irrelevant expressions.
Run 2
Code Structure: The class is logically organized into a field, constructor, accessor, and encoder, but irrelevant assertions disrupt otherwise clean methods. Nesting: Methods are shallow, with only single-level conditional blocks. Clarity of intent: Names, types, and documentation clearly describe a SOCKS initialization response; hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: The implementation is short, but three redundant checks add unnecessary noise. Action granularity: Most lines perform one action, while each assertion line compresses a condition, block, and throw statement. Reading flow: The normal constructor-to-accessor-to-encoder progression is natural, but unindented checks interrupt visual consistency and force readers to inspect meaningless expressions.
Run 3
Code Structure: The class is logically organized around a field, constructor, accessor, and encoder, but irrelevant assertion guards interrupt each method. Nesting: Minimal nesting keeps the code easy to follow. Clarity of intent: Descriptive names and documentation make the SOCKS response purpose clear; hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: The implementation is short, but the redundant guards add unnecessary code. Action granularity: Core operations occupy separate lines, while each guard compresses a condition and throw onto one line. Reading flow: Methods follow a natural order, but unindented guards disrupt visual consistency and distract from the straightforward initialization and serialization logic.