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 due to its clear logical organization, minimal nesting, and concise structure. Each method has a single clear purpose, and actions are separated into distinct lines, improving comprehension. The class encapsulates its responsibility well, with proper use of validation and encapsulation. The Javadoc comments briefly explain the class's role and its relationships. The encodeAsByteBuf method follows a natural linear flow with clear operations. The only minor deductions are for the slight repetition in the Javadoc for authScheme() and the lack of explicit constructor documentation, but neither significantly impacts readability.
Run 3
The code is highly readable. It follows a clear, logical structure with fields, constructor, getter, and override, making the purpose obvious. Nesting is absent, and action granularity is well-followed—each line performs one operation. The code is concise but not oversimplified, with appropriate Javadoc explaining the class and method. Reading flow is natural and intuitive, aided by meaningful naming and consistent formatting. One minor deduction: the class-level Javadoc is slightly ambiguous ('An socks init response' has a grammatical error), but it does not meaningfully obscure intent.
Run 1
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 response initialization, and null validation make the purpose clear; encoding details rely slightly on protocol knowledge. Code length: The implementation is concise, though accessor documentation is repetitive. Action granularity: Each statement performs one clear action. Reading flow: The progression from initialization to access and serialization is natural. Minor issues include missing spacing after the package declaration and the grammatical error in the class documentation.
Run 2
Code Structure: Logically organized into a field, constructor, accessor, and encoding method. Nesting: Flat, with no conditional or loop nesting. Clarity of intent: Descriptive class, field, and method names clearly convey a SOCKS initialization response and its serialization. Code length: Concise implementation, though the accessor documentation is slightly repetitive. Action granularity: Each statement performs a single clear action; the two byte writes make serialization order explicit. Reading flow: Natural progression from initialization to access and encoding. Minor presentation issues, including the missing blank line after the package declaration and the grammatical error in the class documentation, prevent a perfect score.
Run 3
Code Structure: The class is logically organized into a field, constructor, accessor, and encoding method. Nesting: Methods are flat, with no conditionals or loops. Clarity of intent: Descriptive names, null validation, and straightforward byte writes make the purpose clear. Code length: The implementation is concise, though the accessor documentation is somewhat repetitive. Action granularity: Each statement performs a single clear action. Reading flow: The progression from initialization to access and serialization is natural. Minor presentation issues, including the missing blank line after the package declaration and the grammatical error in the class comment, slightly reduce polish.