Source code
package io.netty.resolver.dns;
import io.netty.channel.AddressedEnvelope;
import io.netty.channel.Channel;
import io.netty.channel.ChannelFuture;
import io.netty.handler.codec.dns.DefaultDnsQuery;
import io.netty.handler.codec.dns.DnsQuery;
import io.netty.handler.codec.dns.DnsQuestion;
import io.netty.handler.codec.dns.DnsRecord;
import io.netty.handler.codec.dns.DnsResponse;
import io.netty.util.concurrent.Future;
import io.netty.util.concurrent.Promise;
import java.net.InetSocketAddress;
final class TcpDnsQueryContext extends DnsQueryContext {
TcpDnsQueryContext(Channel cha,
InetSocketAddress name,
DnsQueryContextManager query,
DnsQueryLifecycleObserver lifecycle,
int max, boolean recursion,
long query2,
DnsQuestion que, DnsRecord[] add,
Promise<AddressedEnvelope<DnsResponse, InetSocketAddress>> pro) {
super(cha, name, query, lifecycle, max, recursion,
// No retry via TCP.
query2, que, add, pro, null, false);
}
@Override
protected DnsQuery new2(int id, InetSocketAddress name2) {
return new DefaultDnsQuery(id);
}
@Override
protected String pro() {
return "TCP";
}
}
Run 1
The code has a logical structure with a package declaration, imports, class definition, constructor, and method overrides. However, readability is significantly reduced by abbreviated parameter names ('cha', 'name', 'query', 'max', 'que', 'add', 'pro', 'query2') that obscure intent. The constructor has many parameters, making it long and difficult to follow. While nesting is minimal and action granularity is acceptable, the reading flow is disrupted by unclear naming. The 'new2' and 'pro' method names are ambiguous. The code is concise but sacrifices clarity through abbreviations. Overall, it is functional but not highly readable due to poor naming choices.
Run 2
The code is minimally structured but heavily compromised by cryptic naming and formatting. Parameters like 'cha', 'que', 'add', and 'pro' obscure intent, and the constructor line length is excessive, hurting readability. The super() call spans multiple lines with a comment interrupting the parameter list, which breaks reading flow. Nesting is flat, which is positive, and method lengths are short. The use of a boolean literal 'false' in the constructor adds opacity. While the logic is simple, the abbreviated names and crammed parameter passing significantly reduce clarity. This likely results from decompiled or obfuscated code, not from deliberate design for human readers.
Run 3
The code is a short class but suffers from poor readability. The constructor has 10 parameters with cryptic names like 'cha', 'name', 'query', 'query2', 'que', 'add', and 'pro', making intent unclear. The parameter 'name' is an InetSocketAddress, which is misleading. The method names 'new2' and 'pro' are ambiguous and provide no context. The code is flat and has one action per line, but the parameter list is long and the super() call is split awkwardly with a comment that disrupts flow. The class is concise but at the cost of clarity. Overall, the code is functional but not self-documenting, requiring external context to understand.
Run 1
Code Structure: The class is logically organized into a constructor and two small overrides, though unused imports add clutter. Nesting: There is no deep nesting, making control flow easy to follow. Clarity of intent: The class name and TCP retry comment communicate its role, but abbreviated or arbitrary names such as cha, query2, que, pro, and new2 obscure parameter meanings and method purposes. Code length: The implementation is concise, although the long constructor signature and positional superclass arguments require careful mapping. Action granularity: Each statement performs one clear action; multiple parameters per line slightly reduce scanability. Reading flow: Constructor-first organization and simple overrides provide a natural flow, but poor naming, densely grouped imports, and the lengthy superclass call interrupt understanding.
Run 2
Code Structure: The small class is logically organized into a constructor and two overrides, although unused imports add clutter. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class name, TCP return value, and retry comment convey its purpose, but names such as new2, pro, query2, que, and add obscure method and parameter meanings. The long positional superclass call also requires external context to understand. Code length: The implementation is concise, with little unnecessary code beyond unused imports. Action granularity: Each statement performs one action; wrapping the constructor signature and superclass call is appropriate. Reading flow: The constructor-to-overrides sequence is natural, but inconsistent parameter naming and dense argument lists interrupt comprehension.
Run 3
Code Structure: A small, logically organized class separates construction from two overridden methods, though unused imports add clutter. Nesting: No nested control flow, making the code easy to scan. Clarity of intent: The class name, superclass, TCP return value, and retry comment convey its role, but abbreviated or arbitrary names such as cha, query2, que, pro, and new2 obscure parameter and method meanings. Code length: Concise overall, although the long constructor signature and positional superclass arguments require effort to interpret. Action granularity: Each statement performs a single action; grouping multiple parameters on some lines slightly reduces scanability. Reading flow: Constructor-first ordering followed by overrides is natural, but inconsistent parameter wrapping and weak naming interrupt comprehension.