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() {
return authScheme;
}
@Override
public void encodeAsByteBuf(ByteBuf byteBuf) {
byteBuf.writeByte(protocolVersion().byteValue());
byteBuf.writeByte(authScheme.byteValue());
}
}
Run 1
The code is highly readable. It has a clear, single-purpose class with a flat structure and minimal nesting. The constructor and methods are straightforward, each performing one clear action. Javadoc comments adequately explain the class, constructor parameter, and return value. Naming is consistent with Netty conventions, and the code is concise without being overly terse. The encodeAsByteBuf method reads naturally, writing the protocol version then the auth scheme. Minor points: the class-level comment is slightly terse ('An socks init response') and could be more descriptive, but this does not meaningfully impact readability. Overall, it follows clean code principles effectively.
Run 2
The code is highly readable. It has a clear structure with a single purpose: representing a SOCKS initialization response. There is no deep nesting, and the class is concise with only necessary fields and methods. The constructor validates input using ObjectUtil.checkNotNull, making intent explicit. Methods are granular, with one action per line in encodeAsByteBuf. The naming is clear (authScheme, protocolVersion, encodeAsByteBuf) and follows Java conventions. The only minor deduction is that the Javadoc could be slightly more descriptive, but overall the flow is natural and easy to follow.
Run 3
The code is highly readable. It follows a clear, logical structure with minimal nesting. The class has a single responsibility and clearly expresses its intent through descriptive naming and Javadoc. The constructor validates input explicitly, and the encodeAsByteBuf method performs one action per line, making the flow natural. The code is concise with no unnecessary verbosity. The only minor drawback is the redundant Javadoc on the authScheme() accessor, but it does not significantly impact readability.
Run 1
Code Structure: The class is logically organized into a field, constructor, accessor, and encoding method. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: Descriptive class, field, and method names clearly communicate the response's purpose; constructor validation is explicit. Code length: The implementation is concise, though the accessor documentation is slightly repetitive. Action granularity: Each statement performs one clear action, including separate writes for protocol version and authentication scheme. Reading flow: The progression from initialization to access and serialization is natural. Minor presentation issues include the missing blank line after the package declaration and the grammatical error 'An socks init response.'
Run 2
Code Structure: The class is logically organized into a field, constructor, accessor, and encoding method. Nesting: All methods are flat, with no conditional or loop nesting. Clarity of intent: Descriptive class, field, and method names make the response's purpose clear; constructor validation explicitly enforces a non-null authentication scheme. Code length: The implementation is concise, although the accessor documentation is slightly repetitive. Action granularity: Each statement performs one clear action, including separate writes for the protocol version and authentication scheme. Reading flow: The progression from initialization to access and serialization is natural. Minor presentation issues, such as missing spacing between the package declaration and imports and the grammatical error in the class documentation, slightly reduce polish.
Run 3
Code Structure: The class is logically organized into a field, constructor, accessor, and encoding method. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive class, field, and method names make the SOCKS initialization response and its serialization clear. Code length: The implementation is concise; accessor documentation is slightly repetitive. Action granularity: Each statement occupies its own line and performs a focused operation. Reading flow: The progression from initialization to access and encoding is natural. Minor issues include missing spacing between the package declaration and imports and the grammatical error in the class documentation.