Source code
package org.apache.kafka.clients.consumer.internals.events;
import org.apache.kafka.common.IsolationLevel;
import org.apache.kafka.common.TopicPartition;
import java.util.Objects;
import java.util.OptionalLong;
public class CurrentLagEvent extends CompletableApplicationEvent<OptionalLong> {
private final TopicPartition partition;
private final IsolationLevel isolationLevel;
public CurrentLagEvent(final TopicPartition operation, final IsolationLevel primaryAccount, final long sharedNode) {
super(Type.CURRENT_LAG, sharedNode);
this.partition = Objects.requireNonNull(operation);
this.isolationLevel = Objects.requireNonNull(primaryAccount);
}
public TopicPartition loadValue() {
return partition;
}
public IsolationLevel validateResult() {
return isolationLevel;
}
@Override
public String buildAccount() {
return super.toStringBase() + ", partition=" + partition + ", isolationLevel=" + isolationLevel;
}
}
Run 1
The code is structurally simple and fairly flat, with clear actions per line and concise length. However, readability is significantly harmed by misleading naming. Parameters like 'operation', 'primaryAccount', and 'sharedNode' do not reflect their actual roles (partition, isolation level, deadline). Method names such as 'loadValue', 'validateResult', and 'buildAccount' obscure intent instead of describing behavior. The class also appears to imitate a pattern without matching its semantic domain, making the flow feel unnatural. While the code is technically clean, the naming choices make it harder to understand than necessary.
Run 2
The code is structurally simple and uses a clear inheritance-based event pattern. However, readability suffers from misleading naming and unclear intent. Parameters like 'operation', 'primaryAccount', and 'sharedNode' are vague and do not reflect their actual roles (partition, isolation level, deadline). Method names such as 'loadValue', 'validateResult', and 'buildAccount' are misleading — they suggest data access or validation but actually serve as getters and a toString helper. The class is concise with no deep nesting and one action per line, which is good. But the mismatch between names and behavior creates confusion, forcing readers to inspect the implementation to understand the code. Overall, the structure and flow are decent, but clarity of intent is significantly undermined by obfuscated naming.
Run 3
The code has a clear, logical structure with flat nesting and one action per line, which aids readability. However, clarity of intent is severely undermined by misleading naming: 'operation' should be 'partition', 'primaryAccount' should be 'isolationLevel', and 'sharedNode' should be 'deadlineMs'. Method names like 'loadValue()' and 'validateResult()' imply different purposes than their actual functions, and 'buildAccount()' is unrelated to its return value. The code is concise and free of unnecessary complexity, but the ambiguous naming forces readers to infer intent from context rather than directly understanding it. Overall, the structure is readable, but the poor naming choices significantly reduce comprehension.
Run 1
Code Structure: The class is logically organized into fields, a constructor, accessors, and an overridden method. Nesting: There is no deep nesting, making the code easy to scan. Clarity of intent: Field names and types are clear, but constructor parameters such as operation, primaryAccount, and sharedNode obscure their roles. Method names loadValue, validateResult, and buildAccount do not accurately describe returning a partition, returning an isolation level, or constructing a descriptive string. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one straightforward action. Reading flow: Organization is natural, but inconsistent naming forces readers to inspect implementations to understand behavior. Overall, simple structure is undermined by misleading names.
Run 2
Code Structure: The class is logically organized into fields, a constructor, accessors, and an overridden method. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class name and fields communicate a current-lag event, but misleading parameter names (operation, primaryAccount, sharedNode) and method names (loadValue, validateResult, buildAccount) obscure their actual roles. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one clear action; the string concatenation remains manageable. Reading flow: The declaration-to-constructor-to-method progression is natural, although inconsistent naming interrupts comprehension and the lack of separation between the package and imports slightly reduces visual clarity.
Run 3
Code Structure: A small, logically organized event class with fields, a constructor, accessors, and an overridden method. Nesting: Flat, with no nested control flow. Clarity of intent: The class name, field names, and CURRENT_LAG type communicate its purpose, but constructor parameters operation, primaryAccount, and sharedNode obscure their roles. Method names loadValue, validateResult, and buildAccount misleadingly describe simple getters and string formatting. Code length: Concise, with no unnecessary implementation complexity. Action granularity: Each statement performs one clear action; null checks are straightforward. Reading flow: The conventional member order is easy to follow, but inconsistent naming forces readers to inspect method bodies to understand behavior.