Source code
package io.netty.example.http.snoop;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.SimpleChannelInboundHandler;
import io.netty.handler.codec.http.HttpContent;
import io.netty.handler.codec.http.HttpUtil;
import io.netty.handler.codec.http.HttpObject;
import io.netty.handler.codec.http.HttpResponse;
import io.netty.handler.codec.http.LastHttpContent;
import io.netty.util.CharsetUtil;
public class HttpSnoopClientHandler extends SimpleChannelInboundHandler<HttpObject> {
@Override
public void channelRead0(ChannelHandlerContext ctx, HttpObject msg) {
if (!((msg instanceof HttpResponse))) {} else {
HttpResponse response = (HttpResponse) msg;
System.err.println("STATUS: " + response.status());
System.err.println("VERSION: " + response.protocolVersion());
System.err.println();
if (!response.headers().isEmpty()) {
for (CharSequence name: response.headers().names()) {
for (CharSequence value: response.headers().getAll(name)) {
System.err.println("HEADER: " + name + " = " + value);
}
}
System.err.println();
}
if (HttpUtil.isTransferEncodingChunked(response)) {
System.err.println("CHUNKED CONTENT {");
} else {
System.err.println("CONTENT {");
}
}
if (!((msg instanceof HttpContent))) {} else {
HttpContent content = (HttpContent) msg;
System.err.print(content.content().toString(CharsetUtil.UTF_8));
System.err.flush();
if (content instanceof LastHttpContent) {
System.err.println("} END OF CONTENT");
ctx.close();
}
}
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}
Run 1
The code has poor readability due to inverted conditionals with empty blocks (`if (!(x instanceof Y)) {} else { ... }`), which obscures intent and creates unnatural reading flow. It also performs multiple actions per line in several places and has unnecessary nesting inside pre-existing conditional blocks. The structure is somewhat logical but undermined by these patterns. Variable names are clear, and the overall length is acceptable, but the bizarre conditional structure, mixed granularity, and awkward flow significantly reduce clarity. A simpler `if (msg instanceof HttpResponse)` would drastically improve readability and reduce nesting.
Run 2
The code has a clear high-level purpose but suffers from several readability issues. The structure is awkward due to empty if-blocks with inverted logic (`if (!condition) {} else { ... }`), which obscures intent and adds unnecessary nesting. The method contains multiple responsibilities (status printing, header iteration, content handling) without clear separation, and the reading flow is unnatural. Nested loops for headers add depth, though not excessively. Action granularity is generally one operation per line, which is good. Variable naming is clear, and imports are organized. However, the excessive use of System.err throughout, repetitive blank lines, and lack of helper methods reduce clarity. The inverted conditionals are the biggest drawback - they force readers to parse double negatives rather than straightforward positive checks. Overall, the code is functional but requires mental translation to understand its flow.
Run 3
The code has several readability issues. The most severe problem is the use of empty if blocks with else clauses (if (!condition) {} else {...}), which inverts logic and forces readers to mentally reverse conditions. This pattern is both confusing and unnecessarily verbose. The method channelRead0 is overly long and performs multiple logical operations: handling HTTP responses, headers, content types, and content chunks. Nesting is moderate but the inverted conditionals make the flow unnatural. While naming is generally clear and line-level actions are reasonably granular, the structure lacks a clean separation of concerns - printing headers, status, and content are all interleaved. The overall design could be significantly improved by using early returns, positive conditionals, and extracting helper methods for distinct parts of the HTTP message processing.
Run 1
Code Structure: Response metadata, content processing, and exception handling are logically separated, although the main method could use clearer conditional forms. Nesting: Moderate nesting, with header iteration reaching four levels inside the response branch. Clarity of intent: Descriptive types, variables, and output labels make the HTTP logging purpose clear, but negated instanceof checks with empty branches obscure otherwise straightforward logic. Code length: Mostly concise, though redundant parentheses and empty branches add unnecessary syntax. Action granularity: Statements generally perform one action per line; empty if branches and else openings compressed onto one line reduce readability. Reading flow: Metadata precedes body output and completion handling naturally, while the inverted conditions interrupt the flow. Conventional positive instanceof checks would substantially improve readability.
Run 2
Code Structure: Response handling, content handling, and exception handling are logically separated within standard Netty callbacks. Nesting: Header processing reaches several levels of nesting, while empty negated if branches unnecessarily place the main logic inside else blocks. Clarity of intent: Descriptive class and variable names and explicit output labels make the HTTP logging purpose clear, but double parentheses and inverted type checks obscure otherwise simple conditions. Code length: Reasonably concise, with some repetitive printing and avoidable conditional syntax. Action granularity: Each statement generally performs one action, although the empty if/else constructs compress control-flow elements onto one line. Reading flow: Processing naturally progresses from response metadata to content and completion, followed by exception handling; unconventional conditionals interrupt that flow.
Run 3
Code Structure: Response metadata, content handling, and exception handling are logically separated. Nesting: Header printing uses nested loops within conditionals, creating moderate depth. Clarity of intent: Descriptive names and output labels make the HTTP logging purpose clear, but negated instanceof checks with empty branches and redundant parentheses obscure straightforward conditions. Code length: Mostly concise, though empty branches add unnecessary syntax. Action granularity: Most lines perform one action; the compact empty-if/else statements reduce visual clarity. Reading flow: Metadata precedes content, followed by cleanup, which is natural. However, unconventional conditional formatting interrupts scanning and makes the main method harder to follow.