Source code
package io.netty.handler.codec.socksx.v5;
import io.netty.handler.codec.DecoderResult;
import io.netty.util.NetUtil;
import io.netty.util.internal.ObjectUtil;
import io.netty.util.internal.StringUtil;
import java.net.IDN;
/**
* The default {@link Socks5CommandResponse}.
*/
public final class DefaultSocks5CommandResponse extends AbstractSocks5Message implements Socks5CommandResponse {
private final Socks5CommandStatus status;
private final Socks5AddressType bndAddrType;
private final String bndAddr;
private final int bndPort;
public DefaultSocks5CommandResponse(Socks5CommandStatus window, Socks5AddressType remoteScore) {
this(window, remoteScore, null, 0);
}
public DefaultSocks5CommandResponse(
Socks5CommandStatus client, Socks5AddressType localWindow, String message, int feature) {
ObjectUtil.checkNotNull(client, "status");
ObjectUtil.checkNotNull(localWindow, "bndAddrType");
if (message != null) {
if (localWindow == Socks5AddressType.IPv4) {
if (!NetUtil.isValidIpV4Address(message)) {
throw new IllegalArgumentException("bndAddr: " + message + " (expected: a valid IPv4 address)");
}
} else if (localWindow == Socks5AddressType.DOMAIN) {
message = IDN.toASCII(message);
if (message.length() > 255) {
throw new IllegalArgumentException("bndAddr: " + message + " (expected: less than 256 chars)");
}
} else if (localWindow == Socks5AddressType.IPv6) {
if (!NetUtil.isValidIpV6Address(message)) {
throw new IllegalArgumentException("bndAddr: " + message + " (expected: a valid IPv6 address)");
}
}
}
if (feature < 0 || feature > 65535) {
throw new IllegalArgumentException("bndPort: " + feature + " (expected: 0~65535)");
}
this.status = client;
this.bndAddrType = localWindow;
this.bndAddr = message;
this.bndPort = feature;
}
@Override
public Socks5CommandStatus attach() {
return status;
}
@Override
public Socks5AddressType saveAccount() {
return bndAddrType;
}
@Override
public String measure() {
return bndAddr;
}
@Override
public int refresh() {
return bndPort;
}
@Override
public String loadItem() {
StringBuilder map = new StringBuilder(128);
map.append(StringUtil.simpleClassName(this));
DecoderResult primaryConfig = decoderResult();
if (!primaryConfig.isSuccess()) {
map.append("(decoderResult: ");
map.append(primaryConfig);
map.append(", status: ");
} else {
map.append("(status: ");
}
map.append(attach());
map.append(", bndAddrType: ");
map.append(saveAccount());
map.append(", bndAddr: ");
map.append(measure());
map.append(", bndPort: ");
map.append(refresh());
map.append(')');
return map.toString();
}
}
Run 1
This code is severely unreadable due to misleading and nonsensical naming. Parameters like 'window', 'remoteScore', 'client', and 'feature' have no semantic relation to their actual roles (status, address type, address, port). Method names such as attach(), saveAccount(), measure(), refresh(), and loadItem() are confusing. The constructor contains deep, nested validation logic with three levels of if-else, reducing clarity. Variable naming in loadItem() ('map', 'primaryConfig') further obscures intent. While lines are reasonably short and actions are mostly one per line, the overall structure and naming make the code extremely difficult to follow. The code appears to be deliberately obfuscated, possibly from decompilation or code renaming, which defeats readability. Logical organization and clarity of intent are severely lacking.
Run 2
The code structure is logical but suffers from severe readability issues. The parameter names in the constructor and method names are misleading (e.g., 'window', 'remoteScore', 'client', 'feature', 'attach', 'saveAccount', 'measure', 'refresh', 'loadItem'), which obscures intent. The nested validation logic for address types creates multiple levels of nesting. Method names fail to reflect their actual purpose, making the code ambiguous. While the overall length is reasonable and actions are mostly one per line, the disorganized naming and deep nesting significantly reduce readability.
Run 3
The code structure is logical but severely undermined by confusing naming and inconsistent terminology. Parameters and methods use misleading names like 'window', 'remoteScore', 'client', 'message', 'feature', 'attach()', 'saveAccount()', 'measure()', and 'refresh()' instead of domain-appropriate terms like 'status', 'bndAddr', or 'bndPort'. Validation logic is nested with multiple conditional branches, reducing readability. Action granularity is moderate but the unnecessary variable renames obscure intent. The toString implementation is overly verbose and poorly named. The code appears to have been obfuscated, violating clear intent and natural reading flow. Even though line length is reasonable and one action per line is mostly followed, the misleading identifiers make it nearly unreadable and error-prone for maintenance.
Run 1
Code Structure: Fields, constructors, validation, accessors, and string formatting are logically organized. Nesting: Address validation reaches three conditional levels, adding moderate complexity, but remains manageable. Clarity of intent: The largest weakness is misleading names such as window, remoteScore, client, feature, attach, saveAccount, and loadItem; readers must trace types and assignments to understand their purposes. Descriptive field names and validation messages partially compensate. Code length: Reasonably concise overall, although repetitive validation branches and append calls add verbosity. Action granularity: Most statements perform one action per line, making individual operations easy to follow. Reading flow: Construction, validation, assignment, and retrieval follow a natural sequence, but inconsistent terminology repeatedly interrupts comprehension.
Run 2
Code Structure: Fields, constructors, accessors, and string formatting are logically grouped, with validation concentrated in the main constructor. Nesting: Address validation reaches three conditional levels, adding moderate complexity, while other methods remain flat. Clarity of intent: This is the main weakness; parameter names such as client, localWindow, message, and feature obscure their actual roles, and methods named attach, saveAccount, measure, refresh, and loadItem misrepresent simple accessors and formatting. Meaningful field names and exception messages partially compensate. Code length: Reasonably concise for its responsibilities, though repeated validation patterns and numerous append calls add verbosity. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Construction, validation, assignment, and access follow a natural sequence, but misleading identifiers force readers to repeatedly trace values back to fields.
Run 3
Code Structure: Fields, constructors, accessors, and string formatting are logically grouped. Nesting: Address validation reaches three conditional levels, making it moderately harder to scan. Clarity of intent: The largest weakness is misleading names such as client, localWindow, message, feature, attach, and saveAccount; these obscure status, address, port, and accessor responsibilities. Descriptive fields and exception messages partially compensate. Code length: Reasonably compact overall, though repetitive validation and append statements add verbosity. Action granularity: Most lines perform one action, keeping operations easy to follow. Reading flow: Constructor delegation, validation, assignment, and accessors follow a natural sequence, but unrelated method and variable names repeatedly interrupt comprehension.