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 follows a clear, logical structure with a single class focusing on one responsibility. It uses minimal nesting, has clear intent through well-named methods and Javadoc, and is concise without unnecessary code. Each action is on its own line, and the reading flow is natural, from constructor to accessor to override method. The only minor deductions are that the override method lacks a Javadoc comment and the class-level comment could be slightly more descriptive (e.g., 'represents' instead of 'An socks init response').
Run 3
The code is well-structured with clear separation of concerns: class declaration, fields, constructor, accessor, and encode method. It follows a flat, non-nested structure, making it easy to follow. Intent is clear from the class name, method names, and Javadoc. Code length is concise with no unnecessary boilerplate. Each action is on its own line, especially in the encode method. Reading flow is natural: field, constructor, getter, then behavior. The only minor drawback is the somewhat redundant Javadoc on the accessor, but this is common in Netty projects and does not harm readability.
Run 1
Code Structure: The class is logically organized into a field, constructor, accessor, and encoding method. Nesting: The code is flat, with no nested control flow. Clarity of intent: Descriptive class, method, and field names make the response's purpose clear; constructor validation explicitly rejects null authentication schemes. Code length: The implementation is concise, though the accessor documentation is slightly repetitive. Action granularity: Each statement performs one focused action on its own line. Reading flow: The progression from initialization to access and serialization is natural. Minor readability issues include the grammatical error in the class documentation ('An socks') and the missing blank line between the package declaration and imports.
Run 2
Code Structure: The class is logically organized into a field, constructor, accessor, and encoding method. Nesting: Methods are flat, with no conditional or loop nesting. Clarity of intent: Descriptive names and explicit null validation make the response's purpose clear; encoding writes the protocol version followed by the authentication scheme. Code length: The implementation is concise, although the accessor documentation is slightly repetitive. Action granularity: Each statement performs a single clear action. Reading flow: The progression from initialization to access to serialization is natural. Minor formatting and documentation issues, such as no blank line after the package declaration and the phrase 'An socks init response,' 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 names, explicit null validation, and straightforward byte writes clearly convey the response's purpose. Code length: The implementation is concise, though the accessor documentation is slightly repetitive. Action granularity: Each statement performs one clear action on its own line. Reading flow: The progression from initialization to access and serialization is natural. Minor issues include missing spacing between the package declaration and imports and the grammatical error 'An socks init response.'