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 has reasonable logical organization and flat nesting, but readability suffers from poor formatting. Multiple statements are placed on the same line as declarations, method signatures, and opening braces, which disrupts the natural reading flow and reduces clarity of intent. While the class is concise, the compressed layout makes it unnecessarily difficult to scan. Each action is not clearly separated onto its own line, and the reading flow feels disorganized. With standard formatting—placing each statement and brace on separate lines—the readability would improve significantly. The code is not unreadable, but the formatting issues keep it from being highly readable.
Run 2
The code is functional but poorly formatted, which hurts readability. The structure is logical, but the layout is tangled: constructor and method signatures are placed on the same line as fields and other declarations. Nesting is shallow, and each action is mostly separate, but line breaks are misused (e.g., `public SocksAuthScheme authScheme() { return authScheme; }` on one line). Intent is clear due to Javadoc, but comments are inconsistently placed. Code length is short, which is good. However, reading flow is disrupted because related code is not visually separated or aligned. Proper formatting—putting braces on their own lines, separating method declarations, and aligning Javadoc—would significantly improve the score. The logic itself is easy to follow, but the current presentation makes it unnecessarily difficult to scan.
Run 3
The code is a small class with a clear purpose, but readability is undermined by severe formatting issues. Multiple statements are packed onto single lines (field declaration, constructor, methods), disrupting action granularity and reading flow. The comments also break natural structure by being placed mid-line. Nesting is flat and the code is concise, which is good, but the lack of line breaks makes it feel dense and harder to scan. The class name and intent are clear, but the visual layout prevents a higher score despite the simple logic.
Run 1
Code Structure: The class logically groups its field, constructor, accessor, and encoder, but compressed formatting weakens visual separation. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names, explicit null validation, and documentation clearly convey the response's purpose. Code length: The implementation is concise without unnecessary logic, although accessor documentation is repetitive. Action granularity: Field and constructor declarations share a line, while method declarations, statements, and closing braces are crowded together, reducing scanability. Reading flow: The member order is natural, but inconsistent line breaks and inline annotations interrupt an otherwise straightforward reading experience.
Run 2
Code Structure: The class logically separates state, construction, access, and encoding, but compressed formatting obscures these boundaries. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names, explicit types, and documentation clearly communicate the response's purpose. Code length: Appropriately short, although the getter documentation is repetitive. Action granularity: The field and constructor declaration share a line, and method declarations, statements, and closing braces are crowded together. Reading flow: The member order is natural, but inconsistent line breaks and inline annotations interrupt scanning. Conventional formatting would substantially improve readability without changing the logic.
Run 3
Code Structure: The class logically groups its field, constructor, accessor, and encoder, but compressed formatting obscures member boundaries. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive types and method names, null validation, and documentation clearly communicate purpose. Code length: Appropriately short for a simple response class, although the accessor documentation is repetitive. Action granularity: The field and constructor share a line, and method declarations, statements, and closing braces are crowded together rather than consistently separated. Reading flow: The constructor-to-accessor-to-encoder sequence is natural, but inline annotations and irregular line breaks interrupt scanning.