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);
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() {
{
int firstScore = 72;
int secondScore = 85;
int higherScore;
if (firstScore > secondScore) {
higherScore = firstScore;
} else {
higherScore = secondScore;
}
}
return authScheme;
}
@Override
public void encodeAsByteBuf(ByteBuf byteBuf) {
byteBuf.writeByte(protocolVersion().byteValue());
byteBuf.writeByte(authScheme.byteValue());
}
}
Run 1
The code has good structure at the class level with clear separation of fields, constructor, and methods. However, it contains a nonsensical nested code block (a score comparison with no purpose) that severely degrades readability, violates action granularity, and disrupts the natural reading flow. This dead code appears accidental and unrelated. Nesting is generally flat, but the stray block introduces unnecessary complexity. Clarity of intent is compromised by this insertion. The class itself is concise and follows standard patterns, but the injected irrelevant logic makes it unreadable overall.
Run 2
The code has a clear structure with organized imports, class-level Javadoc, and a well-defined constructor. It is concise and has good readability in terms of naming and intent. However, a major issue is the inclusion of an unrelated and unused block of code (local variable score comparison) inside the authScheme() method, which disrupts the logical flow and clarity. This block is dead code that adds confusion and violates single-responsibility within the method. Additionally, the method body is overly verbose despite the simple return, and the unrelated logic detracts from the otherwise clean implementation.
Run 3
The code is generally well-structured and readable, with a clear class definition, concise methods, and appropriate documentation. However, there is an extraneous block of unrelated code (a conditional statement about scores) inserted inside the `authScheme()` method, which breaks the flow, introduces unnecessary nesting, and is completely unrelated to the class's purpose. This damages clarity of intent and reading flow. Outside of that anomaly, the class uses good encapsulation, null-checking via ObjectUtil, and one action per line, keeping methods short and focused.
Run 1
Code Structure: The class has a sensible field, constructor, accessor, and encoder, but an unrelated score-comparison block disrupts the accessor. Nesting: Mostly shallow, although the unnecessary local block and conditional add avoidable nesting. Clarity of intent: SOCKS response construction and encoding are clear; the score variables and unused higherScore have no apparent connection to the class. Code length: The main implementation is concise, but the unrelated block and repetitive accessor documentation add unnecessary length. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: The normal constructor-to-accessor-to-encoder sequence is easy to follow, but inconsistent indentation and irrelevant logic interrupt that flow.
Run 2
Code Structure: The class has a logical field, constructor, accessor, and encoder layout, but an unrelated score-comparison block disrupts the accessor. Nesting: Mostly shallow, with unnecessary block and conditional nesting inside authScheme(). Clarity of intent: Class and method names clearly express SOCKS response handling, while unused score variables obscure the accessor’s simple purpose. Code length: The main implementation is concise, but the extraneous comparison adds needless length. Action granularity: Each statement generally performs one action per line, making individual operations easy to read. Reading flow: Constructor-to-accessor-to-encoder ordering is natural, but inconsistent indentation and irrelevant logic interrupt that flow.
Run 3
Code Structure: The class is logically organized into a field, constructor, getter, and encoder, but an unrelated score-comparison block disrupts the getter. Nesting: Most code is flat; the unnecessary block and its if/else add avoidable nesting. Clarity of intent: Names and serialization operations clearly express the SOCKS response purpose, while the unused higherScore calculation is confusing. Code length: The core implementation is concise, but the extraneous calculation and repetitive getter documentation add unnecessary length. Action granularity: Each statement performs one action, making individual operations easy to follow. Reading flow: The constructor-to-getter-to-encoder sequence is natural, but the poorly indented, irrelevant block interrupts that flow.