Source code
package org.apache.kafka.common.requests;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.message.VoteRequestData;
import org.apache.kafka.common.message.VoteResponseData;
import org.apache.kafka.common.protocol.ApiKeys;
import org.apache.kafka.common.protocol.Errors;
import org.apache.kafka.common.protocol.Readable;
import java.util.List;
public class VoteRequest extends AbstractRequest {
public static class Builder extends AbstractRequest.Builder<VoteRequest> {
private final VoteRequestData data;
public Builder(VoteRequestData a) {
super(ApiKeys.VOTE);
this.data = a;
}
@Override
public VoteRequest a(short b) {
return new VoteRequest(data, b);
}
@Override
public String b() {
return data.toString();
}
}
private final VoteRequestData data;
private VoteRequest(VoteRequestData c, short d) {
super(ApiKeys.VOTE, d);
this.data = c;
}
@Override
public VoteRequestData a() {
return data;
}
@Override
public AbstractResponse b(int f, Throwable e) {
return new VoteResponse(new VoteResponseData()
.setErrorCode(Errors.forException(e).code()));
}
public static VoteRequest c(Readable g, short h) {
return new VoteRequest(new VoteRequestData(g, h), h);
}
public static VoteRequestData d(TopicPartition i,
String j,
int k,
int l,
int m,
long n,
boolean o) {
return new VoteRequestData()
.setClusterId(j)
.setTopics(List.of(
new VoteRequestData.TopicData()
.setTopicName(i.topic())
.setPartitions(List.of(
new VoteRequestData.PartitionData()
.setPartitionIndex(i.partition())
.setReplicaEpoch(k)
.setReplicaId(l)
.setLastOffsetEpoch(m)
.setLastOffset(n)
.setPreVote(o))
)));
}
}
Run 1
The code is structurally organized as a request class with a builder, but the obfuscated method and parameter names (e.g., 'a', 'b', 'c', 'd', 'f', 'g', 'h') severely hurt clarity of intent and reading flow. The builder pattern is used, but overridden methods like 'a(short b)' return a VoteRequest without explaining the purpose. While action granularity is mostly one action per line and nesting is moderate, the deeply chained `d` method is long and hard to parse. The import list is concise but lacks explanation of `Readable`. Overall, the code is readable in structure but unreadable in naming, reducing its score significantly.
Run 2
This code is severely unreadable. All meaningful method and parameter names have been replaced with single letters (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o), destroying any clarity of intent. Inheritance and constructors are unclear. While the structure is not deeply nested, the action granularity is poor—the static factory method performs many chained operations. Reading flow is unnatural because names carry no semantic meaning. Code length is acceptable, but every other criterion fails.
Run 3
The code suffers from severe readability issues. Meaningless identifiers (a, b, c, d, f, g, h, i, j, etc.) obscure intent throughout; method names like a(short b) and b(int f, Throwable e) provide no semantic information. Nesting is deep in the Builder.d method with multiple inline setter and List.of chains, making structure hard to follow. Although the code is concise, it fails at clarity of intent—the purpose of parameters and methods is ambiguous. The static factory method d() is especially confusing, mixing many unrelated parameters with poor naming. Error handling in the response builder is terse but reduces clarity. Reading flow is unnatural due to non-descriptive naming and inconsistent action granularity. Overall, this code would require significant renaming and restructuring to be maintainable.
Run 1
Code Structure: The request class, nested builder, and factory methods are logically organized. Nesting: Most methods are flat, but nested object construction and List.of calls make the final method harder to scan. Clarity of intent: Domain types and setter names help, but single-letter method and parameter names obscure operations and argument meanings. Code length: The implementation is concise, with little unnecessary code. Action granularity: Most statements perform one action, and chained setters occupy separate lines, though the final return expression combines several construction steps. Reading flow: The overall progression is reasonable, but inconsistent indentation and clustered closing parentheses interrupt readability. Descriptive names and clearer formatting would substantially improve the code.
Run 2
Code Structure: The request class and nested builder are logically organized, with distinct construction, response, parsing, and data-creation methods. Nesting: Most methods are flat, but the nested fluent construction of topics and partitions requires careful tracking of parentheses. Clarity of intent: Single-letter method and parameter names obscure purpose and meaning; descriptive types and setter names partially compensate. Code length: The code is concise with little unnecessary repetition. Action granularity: Most statements perform one action, although the final return expression combines several object constructions and assignments. Reading flow: Conventional class organization helps, but inconsistent indentation, sparse spacing, and ambiguous names interrupt natural reading.
Run 3
Code Structure: The request class and nested builder are logically organized, with focused methods. Nesting: Most methods are flat, but the nested topic/partition construction requires tracking several levels and closing parentheses. Clarity of intent: Domain types and setter names reveal the purpose, but single-letter method and parameter names obscure operations and argument meanings, especially in the seven-parameter factory. Code length: The implementation is concise with little redundant code. Action granularity: Most statements perform one clear action, though the factory combines multiple object creations and assignments into one chained expression. Reading flow: The builder-to-request-to-factory progression is natural, but inconsistent indentation and cryptic naming interrupt comprehension.