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 a, Socks5AddressType b) {
this(a, b, null, 0);
}
public DefaultSocks5CommandResponse(
Socks5CommandStatus c, Socks5AddressType d, String e, int f) {
ObjectUtil.checkNotNull(c, "status");
ObjectUtil.checkNotNull(d, "bndAddrType");
if (e != null) {
if (d == Socks5AddressType.IPv4) {
if (!NetUtil.isValidIpV4Address(e)) {
throw new IllegalArgumentException("bndAddr: " + e + " (expected: a valid IPv4 address)");
}
} else if (d == Socks5AddressType.DOMAIN) {
e = IDN.toASCII(e);
if (e.length() > 255) {
throw new IllegalArgumentException("bndAddr: " + e + " (expected: less than 256 chars)");
}
} else if (d == Socks5AddressType.IPv6) {
if (!NetUtil.isValidIpV6Address(e)) {
throw new IllegalArgumentException("bndAddr: " + e + " (expected: a valid IPv6 address)");
}
}
}
if (f < 0 || f > 65535) {
throw new IllegalArgumentException("bndPort: " + f + " (expected: 0~65535)");
}
this.status = c;
this.bndAddrType = d;
this.bndAddr = e;
this.bndPort = f;
}
@Override
public Socks5CommandStatus a() {
return status;
}
@Override
public Socks5AddressType b() {
return bndAddrType;
}
@Override
public String c() {
return bndAddr;
}
@Override
public int d() {
return bndPort;
}
@Override
public String e() {
StringBuilder g = new StringBuilder(128);
g.append(StringUtil.simpleClassName(this));
DecoderResult h = decoderResult();
if (!h.isSuccess()) {
g.append("(decoderResult: ");
g.append(h);
g.append(", status: ");
} else {
g.append("(status: ");
}
g.append(a());
g.append(", bndAddrType: ");
g.append(b());
g.append(", bndAddr: ");
g.append(c());
g.append(", bndPort: ");
g.append(d());
g.append(')');
return g.toString();
}
}
Run 1
The code has a problematic mix of clear and confusing elements. The class structure and field declarations are standard, but the parameter names (a, b, c, d, e, f) are completely meaningless, making the constructor and methods hard to understand without reading the full implementation. The validation logic in the constructor is nested three levels deep with multiple if-else branches, making it harder to follow than necessary. The toString() method uses single-letter variables (g, h) and has awkward conditional string building that could be simplified. Method names a(), b(), c(), d(), e() reveal nothing about their purpose. The code violates Java naming conventions and basic readability principles. While the validation logic itself is well-formed and the action granularity is mostly one-per-line, the overall clarity suffers significantly from poor naming choices throughout the entire class.
Run 2
The code suffers from severely poor readability. Parameter names are meaningless single letters (a, b, c, d, e, f, g, h), making intent ambiguous and forcing readers to rely on field assignments to infer purpose. Method names are also single letters (a(), b(), c(), d(), e()), obscuring their functionality. The nested if-else validation logic is moderately deep and could be extracted for clarity. While the overall class structure is organized and toString() follows a logical flow, the terse naming undermines maintainability. Action granularity is acceptable—most lines perform one action—but the constructor mixes validation and assignment. Code length is reasonable, but conciseness is achieved through cryptic abbreviations rather than thoughtful simplification. Reading flow is disrupted by having to mentally map single-letter names to concepts like 'bndAddr' or 'status'. The code is functional but reads like obfuscated or minimized source, failing the clarity and intent criterion completely.
Run 3
The code has a logical class structure and validates inputs, but readability suffers significantly. Constructor parameters use single-letter names (a, b, c, d, e, f) that conceal their purpose, forcing readers to infer meaning from context. Method names like a(), b(), c(), d(), e() are equally unhelpful, obscuring the API's intent. Validation logic uses nested if-else blocks which are acceptable but could be flatter. Action granularity is generally one action per line, which helps, but the toString() method relies on short variable names (g, h) and inline conditionals that interrupt reading flow. Overall, the code is functional but unnecessarily hard to follow due to poor naming and terse identifiers.
Run 1
Code Structure: Fields, constructors, accessors, and string formatting are logically grouped. Nesting: Address validation reaches three conditional levels, adding moderate complexity, while other methods remain flat. Clarity of intent: Descriptive class and field names, validation messages, and library calls help, but single-letter parameters, local variables, and method names significantly obscure meaning. Code length: Overall length is reasonable; repetitive StringBuilder statements make formatting somewhat verbose. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Initialization and validation proceed naturally, but readers must repeatedly map single-letter identifiers to meaningful fields, and opaque accessor calls interrupt comprehension.
Run 2
Code Structure: Logically organized into fields, constructors, accessors, and string formatting, with validation grouped in the main constructor. Nesting: Address validation reaches three conditional levels, adding moderate complexity, while other methods remain flat. Clarity of intent: Descriptive field names and validation messages help, but single-letter parameters, local variables, and method names significantly obscure meaning, particularly the string-formatting method e(). Code length: Reasonably concise for its responsibilities, although repeated validation patterns and append calls add some verbosity. Action granularity: Statements generally perform one action per line, making operations easy to distinguish. Reading flow: Initialization, validation, assignment, and accessors follow a natural sequence, but readers must repeatedly map ambiguous identifiers to their roles.
Run 3
Code Structure: Logically organized into fields, constructors, validation, accessors, and string formatting. Nesting: Address validation reaches three conditional levels, adding moderate complexity, while other methods remain flat. Clarity of intent: Descriptive field names, library calls, and error messages help, but single-letter parameters, methods, and local variables significantly obscure meaning; e() does not clearly indicate its string-formatting purpose. Code length: Reasonably concise overall, though repetitive validation and append calls add verbosity. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Constructor delegation and sequential validation-to-assignment flow are natural, but readers must repeatedly map anonymous identifiers to meaningful fields and infer accessor roles.