Source code
package io.netty.handler.codec.http3;
/**
* State of encoding or decoding for a stream following the <a
* href="https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-http-message-exchanges">
* HTTP message exchange semantics</a>
*/
interface Http3RequestStreamCodecState {
/**
* An implementation of {@link Http3RequestStreamCodecState} that managed no state.
*/
Http3RequestStreamCodecState NO_STATE = new Http3RequestStreamCodecState() {
@Override
public boolean a() {
return false;
}
@Override
public boolean b() {
return false;
}
@Override
public boolean c() {
return false;
}
};
/**
* If any {@link Http3HeadersFrame} or {@link Http3DataFrame} has been received/sent on this stream.
*
* @return {@code true} if any {@link Http3HeadersFrame} or {@link Http3DataFrame} has been received/sent on this
* stream.
*/
boolean a();
/**
* If a final {@link Http3HeadersFrame} has been received/sent before {@link Http3DataFrame} starts.
*
* @return {@code true} if a final {@link Http3HeadersFrame} has been received/sent before {@link Http3DataFrame}
* starts
*/
boolean b();
/**
* If no more frames are expected on this stream.
*
* @return {@code true} if no more frames are expected on this stream.
*/
boolean c();
}
Run 1
The code is functionally simple but severely crippled by obfuscated method names (`a`, `b`, `c`) that make the intent completely ambiguous. The javadoc comments explain what each method means, but the method names themselves fail to communicate purpose without them. The structure is flat and minimal, which helps readability, and the action granularity is one action per line. However, the reading flow is broken because the reader must constantly cross-reference the comments to understand what `a()`, `b()`, and `c()` actually do — something that proper naming like `hasReceivedFrame()`, `isFinalHeadersReceived()`, and `isStreamComplete()` would solve instantly. The anonymous inner class implementation of the `NO_STATE` constant is concise but adds nesting that could be avoided with a lambda or static factory method. The `a href` HTML in the javadoc is not properly escaped for the actual source file context, though this is minor. Overall, while the structure is not tangled, the cryptic naming makes this unreadable in practice.
Run 2
The code has reasonable structure with clear Javadoc on the interface and its methods, but the method names (a, b, c) are completely opaque and destroy clarity of intent. The anonymous NO_STATE implementation adds unnecessary length and noise when a default method or separate class would be cleaner. Nesting is minimal (one level), and the action granularity is fine—each line does one thing—but reading flow is poor because the methods communicate nothing about their purpose. The Javadoc describes behavior well, but the names fail to encode meaning. Concise code, but readability suffers greatly from the naming choices and the inline anonymous class. A more descriptive naming strategy would dramatically improve the score.
Run 3
The code has severe readability issues. The method names 'a', 'b', and 'c' are completely non-descriptive, making the intent impossible to understand without reading the Javadoc comments. This directly violates the 'Clarity of intent' criterion. The structure is logical, using an interface with a default NO_STATE implementation, but the cryptic naming undermines this. Nesting is flat and code length is reasonable, but the anonymous inner class formatting is slightly awkward. Action granularity and reading flow are acceptable, but the lack of meaningful identifiers makes the code effectively unreadable. The Javadoc comments are helpful but cannot compensate for the poor method names that force readers to constantly refer back to documentation.
Run 1
Code Structure: The interface is logically organized, with a stateless implementation followed by documented method declarations. Nesting: Minimal nesting; the anonymous implementation is straightforward. Clarity of intent: Javadoc explains the interface and each method, but opaque names a(), b(), and c() obscure meaning at call sites and require consulting documentation. Code length: The code is reasonably concise, though repeated descriptions in Javadoc add some verbosity. Action granularity: Each declaration and return statement occupies its own line, making individual operations easy to identify. Reading flow: Consistent formatting and method ordering support natural reading, but descriptive method names would substantially improve comprehension.
Run 2
Code Structure: The interface is logically organized, with a no-state implementation followed by documented state queries. Nesting: Shallow; the anonymous implementation adds little complexity. Clarity of intent: The interface name and Javadocs explain the purpose, but method names a(), b(), and c() are opaque and force readers to consult documentation. Code length: The implementation is concise, although the Javadocs repeat descriptions in return tags. Action granularity: Each method performs a single, simple action, and declarations are clearly separated. Reading flow: Consistent formatting and grouping support natural reading, but meaningless method names interrupt comprehension, especially at call sites.
Run 3
Code Structure: The interface is logically organized, with a default stateless implementation followed by documented method declarations. Nesting: Shallow; the anonymous implementation adds only one structural level, with no nested control flow. Clarity of intent: The interface name and Javadocs explain the purpose, but method names a(), b(), and c() are opaque and force readers to consult documentation. Code length: The implementation is concise, although repeated descriptions in Javadocs add some unnecessary length. Action granularity: Each return statement and declaration occupies its own line, keeping actions distinct. Reading flow: Consistent formatting and matching method order make the code easy to follow, but non-descriptive method names interrupt comprehension, particularly at call sites.