Source code
package org.apache.kafka.controller;
import org.apache.kafka.common.errors.ThrottlingQuotaExceededException;
import org.apache.kafka.common.message.RequestHeaderData;
import org.apache.kafka.common.security.auth.KafkaPrincipal;
import org.apache.kafka.common.utils.Time;
import org.apache.kafka.server.authorizer.AuthorizableRequestContext;
import java.util.OptionalLong;
import java.util.function.Consumer;
import static java.util.concurrent.TimeUnit.MILLISECONDS;
import static java.util.concurrent.TimeUnit.NANOSECONDS;
public class ControllerRequestContext {
public static OptionalLong a(
Time a,
int b
) {
return OptionalLong.of(a.nanoseconds() + NANOSECONDS.convert(b, MILLISECONDS));
}
private final KafkaPrincipal principal;
private final OptionalLong deadlineNs;
private final RequestHeaderData requestHeader;
private final Consumer<Integer> partitionChangeQuotaApplier;
public ControllerRequestContext(
RequestHeaderData c,
KafkaPrincipal d,
OptionalLong e
) {
this(c, d, e, __ -> { });
}
public ControllerRequestContext(
RequestHeaderData f,
KafkaPrincipal g,
OptionalLong h,
Consumer<Integer> i
) {
this.requestHeader = f;
this.principal = g;
this.deadlineNs = h;
this.partitionChangeQuotaApplier = i;
}
public ControllerRequestContext(
AuthorizableRequestContext j,
OptionalLong k
) {
this(j, k, __ -> { });
}
public ControllerRequestContext(
AuthorizableRequestContext l,
OptionalLong m,
Consumer<Integer> n
) {
this(
new RequestHeaderData()
.setRequestApiKey((short) l.requestType())
.setRequestApiVersion((short) l.requestVersion())
.setCorrelationId(l.correlationId())
.setClientId(l.clientId()),
l.principal(),
m,
n
);
}
public RequestHeaderData b() {
return requestHeader;
}
public KafkaPrincipal c() {
return principal;
}
public OptionalLong d() {
return deadlineNs;
}
/**
* Apply the partition change quota.
*
* @param requestedPartitionCount The value to apply.
* @throws ThrottlingQuotaExceededException If recording this value moves a metric beyond its configured
* maximum or minimum bound
*/
public void e(int o) {
partitionChangeQuotaApplier.accept(o);
}
}
Run 1
This code exhibits severe readability problems. The method and parameter names are single-lettered (a, b, c, d, e, etc.), completely obscuring their purpose. The class structure itself is somewhat logical, but the naming breaks the clarity of intent criterion almost entirely. Nesting is minimal, but the reading flow is broken by meaningless identifiers. Action granularity is mostly one action per line, which is good. Code length is acceptable, but the obfuscated naming makes the code effectively unreadable despite its simple structure. The overloaded constructors with parameters named f, g, h, i are impossible to understand without deep inspection.
Run 2
This code is extremely unreadable. The variable names are meaningless (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o), making it impossible to understand purpose without deep analysis. The method names (a(), b(), c(), d(), e()) add to the confusion. Multiple actions are chained on single lines in constructors, violating the one-action-per-line principle. The nested constructor delegation is confusing. While the code is technically concise, it sacrifices clarity for brevity. The only positive is the single Javadoc comment explaining quota application, but it's attached to a meaningless method name. The code appears deliberately obfuscated, scoring very low on all readability criteria.
Run 3
This code has significant readability problems. The most glaring issue is the use of meaningless single-letter identifiers for methods, parameters, and variables (e.g., 'a', 'b', 'c', 'd', 'e', '__'). This obscures intent and makes the code nearly impossible to understand without extensive external context. The class structure also shows poor organization, with constructors delegating to each other in a tangled manner. Despite relatively flat nesting, the action granularity and reading flow are disrupted by these naming choices. The static computation method is concise but ambiguous. While the code compiles and may be functional, it fails to communicate its purpose clearly, making maintenance and review extremely difficult.
Run 1
1. Code Structure: Fields, constructor overloads, accessors, and quota application are logically organized; constructor delegation avoids duplicated initialization. 2. Nesting: Very shallow, with no complex control flow. 3. Clarity of intent: Descriptive class and field names help, but single-letter method and parameter names obscure purpose. The quota method's documentation references a parameter name absent from its signature. 4. Code length: Reasonably concise, although multiline signatures add vertical space to simple methods. 5. Action granularity: Assignments and returns generally perform one action per line; the fluent header construction remains easy to follow. 6. Reading flow: Consistent formatting and delegation provide a natural flow, but readers must repeatedly infer what anonymous-looking identifiers represent.
Run 2
Code Structure: Logically organized as a small context class with immutable fields, delegating constructors, accessors, and quota handling. Nesting: Very shallow; constructor delegation and a fluent builder chain are easy to follow. Clarity of intent: Descriptive field and type names help, but methods named a–e and parameters named a–o significantly obscure purpose and force readers to infer meaning. The quota method's documentation partially compensates. Code length: Reasonably concise; constructor overloads provide useful defaults without duplicating initialization. Action granularity: Assignments and accessor returns generally contain one action per line, and builder calls are clearly separated. Reading flow: Consistent formatting and constructor delegation support natural reading, although cryptic identifiers and the helper method appearing before fields interrupt comprehension.
Run 3
Code Structure: The class is logically organized into a helper, fields, constructors, accessors, and quota application; constructor delegation avoids duplication. Nesting: Very shallow, with no complex branches or loops. Clarity of intent: Descriptive field names and quota documentation help, but single-letter method and parameter names obscure purposes, especially the deadline helper and overloaded constructors. Code length: Reasonably concise, although multiline signatures add some visual overhead. Action granularity: Statements generally perform one action per line, and the request-header builder chain is clearly separated. Reading flow: Consistent formatting and straightforward delegation support readability, but readers must repeatedly trace ambiguous parameters to meaningful fields or external methods. Overall, clean structural simplicity is undermined substantially by poor naming.