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) {
{int lI0O_12ae2648=0x4956;lI0O_12ae2648=((lI0O_12ae2648&0)==0)?(((lI0O_12ae2648^lI0O_12ae2648)==0)?0:1):2;}
byteBuf.writeByte(protocolVersion().byteValue());
byteBuf.writeByte(authScheme.byteValue());
}
}
Run 1
The code is highly readable due to its clear structure, minimal nesting, and concise implementation. The class has a single responsibility, with a well-defined constructor and a simple getter method. Intent is clear through meaningful naming (authScheme, encodeAsByteBuf) and Javadoc comments. Each action in encodeAsByteBuf is on its own line, promoting readability. However, a bizarre obfuscated line inside encodeAsByteBuf (the `lI0O_12ae2648` variable assignment) is completely unrelated to the method's purpose, appearing to be dead code or a decompilation artifact. This significantly harms clarity and intent, preventing a perfect score. Without that line, the code would be exemplary.
Run 2
The class has a clear purpose and follows standard Java patterns, with sensible naming and javadoc present. The constructor validates input, and method names are descriptive. However, readability is hurt by a significant issue: an unexplained obfuscated line inside encodeAsByteBuf that serves no functional purpose and introduces confusion. It violates action granularity and clarity of intent. The code is otherwise concise and flat, with good structure, but nesting is minimal and not a problem. The unnatural block formatting around the useless expression breaks reading flow and makes the method harder to scan. Without that block, the code would score higher, around 17 or 18.
Run 3
The code is mostly readable but contains a severe flaw that destroys readability. The class structure is logical, with clear fields, constructor, getter, and encode method. Import statements and Javadoc are present. However, the encodeAsByteBuf method contains an obfuscated line of meaningless integer operations that serves no purpose, likely inserted by a code obfuscator or error. This line breaks the reading flow, obscures intent, and adds unnecessary complexity. Aside from this, the method is concise and flat, with one action per line. The code length is short, but the nonsensical line makes the overall clarity poor. With that line removed, the score would be around 15-17, but as presented it is nearly unreadable in that section.
Run 1
Code Structure: The class is logically organized into a field, constructor, accessor, and encoder, but an unrelated obfuscated block disrupts the encoder. Nesting: Most code is flat; the inserted block introduces nested ternary expressions that complicate reading. Clarity of intent: Descriptive class and method names make the response encoding clear, while the cryptic local variable and redundant bitwise expressions have no apparent purpose. Code length: The legitimate implementation is concise, but the unnecessary block adds noise. Action granularity: Most statements perform one action per line; the inserted block compresses declaration, assignment, and conditional logic onto one line. Reading flow: Conventional Java organization and documentation support a natural flow, interrupted sharply by the unindented, densely packed block.
Run 2
Code Structure: The class is logically organized into a field, constructor, accessor, and encoder, but an unrelated block disrupts the encoder. Nesting: Most code is flat; the inserted block adds nested ternary expressions that complicate reading. Clarity of intent: Descriptive class and method names make the SOCKS response purpose clear, while the cryptic variable and redundant bitwise operations obscure intent. Code length: The functional code is concise, but the unused computation adds unnecessary length. Action granularity: Normal statements perform one action per line; the inserted line combines declaration, assignment, and multiple conditional operations. Reading flow: The constructor-to-accessor-to-encoder progression is natural, but the densely formatted block interrupts it. Overall, readable surrounding code is substantially weakened by a localized obfuscated statement.
Run 3
Code Structure: The class is logically organized into a field, constructor, accessor, and encoder, but an irrelevant block disrupts the encoder. Nesting: Most code is flat; the injected block includes nested ternary expressions that complicate reading. Clarity of intent: Naming and API usage clearly communicate the SOCKS response purpose, while the cryptic local variable and redundant bitwise expressions obscure intent. Code length: The functional implementation is concise, but the injected computation adds unnecessary code. Action granularity: Normal statements perform one action per line; the injected line compresses declaration, assignment, and several expressions together. Reading flow: The constructor-to-accessor-to-encoding progression is natural, but the unexplained block interrupts it. Removing that block would substantially improve readability.