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 status, Socks5AddressType bndAddrType) {
this(status, bndAddrType, null, 0);
}
public DefaultSocks5CommandResponse(
Socks5CommandStatus status, Socks5AddressType bndAddrType, String bndAddr, int bndPort) {
ObjectUtil.checkNotNull(status, "status");
ObjectUtil.checkNotNull(bndAddrType, "bndAddrType");
if (!((bndAddr != null))) {} else {
if (bndAddrType == Socks5AddressType.IPv4) {
if (!NetUtil.isValidIpV4Address(bndAddr)) {
throw new IllegalArgumentException("bndAddr: " + bndAddr + " (expected: a valid IPv4 address)");
}
} else if (bndAddrType == Socks5AddressType.DOMAIN) {
bndAddr = IDN.toASCII(bndAddr);
if (bndAddr.length() > 255) {
throw new IllegalArgumentException("bndAddr: " + bndAddr + " (expected: less than 256 chars)");
}
} else if (bndAddrType == Socks5AddressType.IPv6) {
if (!NetUtil.isValidIpV6Address(bndAddr)) {
throw new IllegalArgumentException("bndAddr: " + bndAddr + " (expected: a valid IPv6 address)");
}
}
}
if (!((bndPort < 0 || bndPort > 65535))) {} else {
throw new IllegalArgumentException("bndPort: " + bndPort + " (expected: 0~65535)");
}
this.status = status;
this.bndAddrType = bndAddrType;
this.bndAddr = bndAddr;
this.bndPort = bndPort;
}
@Override
public Socks5CommandStatus status() {
return status;
}
@Override
public Socks5AddressType bndAddrType() {
return bndAddrType;
}
@Override
public String bndAddr() {
return bndAddr;
}
@Override
public int bndPort() {
return bndPort;
}
@Override
public String toString() {
StringBuilder buf = new StringBuilder(128);
buf.append(StringUtil.simpleClassName(this));
DecoderResult decoderResult = decoderResult();
if (!((!decoderResult.isSuccess()))) {
buf.append("(status: ");
} else {
buf.append("(decoderResult: ");
buf.append(decoderResult);
buf.append(", status: ");
}
buf.append(status());
buf.append(", bndAddrType: ");
buf.append(bndAddrType());
buf.append(", bndAddr: ");
buf.append(bndAddr());
buf.append(", bndPort: ");
buf.append(bndPort());
buf.append(')');
return buf.toString();
}
}
Run 1
The code has several readability issues. First, inverted empty block if statements like `if (!((bndAddr != null))) {} else { ... }` are confusing and should be simplified to `if (bndAddr == null) { ... } else { ... }`. This pattern also makes the code unnecessarily long. Second, the constructor has deep nesting with multiple levels of if-else chains, making it harder to follow. Third, some validation logic could be extracted into helper methods to improve action granularity and structure. The toString method has a similar inverted condition with empty block that obscures intent. However, the class is well-structured, fields are final, and getters are straightforward. The code follows Java conventions for naming and organization. Overall, it's functional but unnecessarily convoluted, reducing readability significantly.
Run 2
The code structure and field organization are clear, and method names communicate intent well. However, readability is significantly damaged by inverted conditionals that create awkward, non-natural flow (e.g., `if (!((bndAddr != null))) {} else { ... }`). Nesting is moderate but made worse by these inverted checks. Action granularity is mostly acceptable, though the constructor is long and mixes validation logic. The `toString()` method suffers from the same inverted conditional problem, making its logic unnecessarily confusing. Concise naming is good, but unnecessarily wrapped or negated conditions hurt clarity.
Run 3
The code has a clear class structure and standard getter/setter methods, but readability is significantly harmed by inverted logic patterns like `if (!condition) {} else { ... }` and double-negated conditions. The constructor validation flow is convoluted: the null/address type checks are nested awkwardly, making intent hard to follow. The `toString` method also uses an unnecessary empty if-block with inverted condition, disrupting natural reading. Action granularity is generally okay, but the overall nesting and inversion creates confusion. Code length is reasonable, but the unusual conditional style adds cognitive overhead. The class structure is logical, but the implementation choices obscure clarity.
Run 1
Code Structure: Fields, constructors, accessors, and string formatting are logically organized. Nesting: Address validation reaches three conditional levels, adding moderate complexity. Clarity of intent: Types, validation messages, and method names convey purpose, but redundant parentheses, negated conditions, and empty if branches obscure straightforward checks. Code length: Mostly appropriate for a response object, though verbose conditionals and repeated append calls add bulk. Action granularity: Statements generally perform one action per line, making operations easy to follow; empty if/else constructs are awkward exceptions. Reading flow: The overall sequence is natural, but inverted validation branches and the double-negative success check interrupt comprehension. Direct positive conditions would substantially improve readability.
Run 2
Code Structure: Fields, constructors, accessors, and string formatting are logically organized. Nesting: Address validation has moderate nesting that could be simplified. Clarity of intent: Class purpose and validation messages are clear, but redundant parentheses, negated conditions, and empty if branches obscure straightforward checks. Code length: Mostly appropriate for a small response class, though validation and string-building boilerplate add verbosity. Action granularity: Most lines perform a single action; the empty-if/else constructs unnecessarily combine control-flow elements on one line. Reading flow: Conventional method ordering and consistent formatting help, but inverted validation branches and the double negation in toString interrupt natural reading.
Run 3
Code Structure: Fields, constructors, accessors, and string formatting are logically organized, with validation localized to the main constructor. Nesting: Address validation has moderate nesting, made unnecessarily awkward by an empty if branch followed by else. Clarity of intent: Types, validation messages, and method names communicate purpose, but redundant parentheses, negated conditions, and double negation obscure straightforward checks. Code length: Generally appropriate for the class, though empty branches and repetitive formatting statements add clutter. Action granularity: Most lines perform a single operation, making validation and assignments easy to follow; the inline empty branches are exceptions. Reading flow: The progression from validation to initialization and accessors is natural, but inverted conditions interrupt comprehension and require mentally simplifying expressions.