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 simple, flat structure with no nesting beyond the class definition. Each method performs a single, clear action: validation and assignment, returning a field, or writing two bytes to a buffer. The intent is unambiguous, aided by descriptive names and a clear class-level Javadoc. The code is concise without being terse; getters, constructors, and encode methods follow standard Netty patterns. Reading flow is natural, moving from field declaration to constructor to accessor to encoding logic. Only minor deductions for the redundant Javadoc on the authScheme() method and the slight verbosity of the protocol write sequence, but overall the code is clean and maintainable.
Run 2
The code is highly readable with clear logical organization, minimal nesting, and concise length. Each method has a single responsibility, and the action granularity is one operation per line. The class structure is straightforward, with a clear field, constructor, getter, and overridden method. Naming is descriptive and JavaDoc comments clarify purpose. The only minor deductions are for the redundant JavaDoc on the getter and slightly verbose import of ObjectUtil, but these do not significantly impact readability.
Run 3
The code is highly readable. It has a clear, logical structure with a single class, a constructor, an accessor, and an overridden encode method. Nesting is minimal and control flow is flat. Intent is explicit through descriptive naming, Javadoc comments, and the use of ObjectUtil.checkNotNull. The code is concise without being cryptic, with one logical action per line. Reading flow is natural, moving from field declaration to constructor to getter to behavior. Minor deductions: the Javadoc could be slightly more detailed, and the class-level comment has a grammatical issue, but these do not materially affect readability.
Run 1
Code Structure: Logically organized into a field, constructor, accessor, and encoding method. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive class, method, and variable names make the response's purpose clear; explicit null validation reinforces the field's contract. Code length: Concise implementation, though the accessor documentation is slightly repetitive. Action granularity: Each statement performs one clear action, and the two encoding writes are separated. Reading flow: Natural progression from initialization to access and serialization. Minor polish issues include the grammatical error 'An socks init response' and the lack of a 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, explicit null validation, and straightforward serialization make the purpose clear. Code length: The implementation is concise; 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 encoding is natural. Minor presentation issues include missing spacing between the package and imports and the grammatical error in the class comment.
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 clearly convey a SOCKS initialization response and its serialization. Code length: The implementation is concise; accessor documentation is slightly repetitive. Action granularity: Each statement performs a single clear action, including separate writes for protocol version and authentication scheme. Reading flow: The progression from initialization to access and encoding is natural. Minor formatting and documentation issues, such as the missing blank line after the package declaration and the phrase 'An socks init response,' slightly reduce polish.