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 a, final IsolationLevel b, final long c) {
super(Type.CURRENT_LAG, c);
this.partition = Objects.requireNonNull(a);
this.isolationLevel = Objects.requireNonNull(b);
}
public TopicPartition a() {
return partition;
}
public IsolationLevel b() {
return isolationLevel;
}
@Override
public String c() {
return super.toStringBase() + ", partition=" + partition + ", isolationLevel=" + isolationLevel;
}
}
Run 1
The code has a clear structure with a single class, constructor, and accessor methods, but it suffers from poor naming conventions. Parameters 'a', 'b', and 'c' obscure the intent, even though the fields 'partition' and 'isolationLevel' are named clearly. The unnatural accessor names 'a()' and 'b()' further reduce clarity and interrupt reading flow. Nesting is minimal and action granularity is good, with one action per line. The code is concise, but the ambiguous naming and odd method names make it less readable than it could be. Overall, the logical organization is sound, but clarity and intent suffer significantly due to non-descriptive identifiers and method names.
Run 2
The code has a clear class structure and short, readable methods, but it suffers from poor naming conventions. Parameter and method names like 'a', 'b', and 'c' obscure the intent, making the code harder to understand at a glance. The logical organization is good with a single responsibility per method and minimal nesting, but the unclear naming reduces the overall readability. The class is concise and follows a natural flow, but the use of non-descriptive names is a significant drawback. The constructor properly uses Objects.requireNonNull, which is a good practice for ensuring non-null inputs. However, the method a() returning partition and b() returning isolationLevel are ambiguous and would benefit from descriptive names. Overall, the code is readable once the intent is inferred, but it lacks the clarity that descriptive naming would provide.
Run 3
The code is logically structured and relatively flat, but parameter and method names (a, b, c) are unhelpful, obscuring intent. Action granularity is okay, but the override of toString as method c() is unclear. Class purpose is evident, but poor naming hurts readability overall.
Run 1
1. Code Structure: Fields, constructor, accessors, and overridden method are logically organized. 2. Nesting: Flat methods with no nested control flow make the code easy to scan. 3. Clarity of intent: The class name, field names, and CURRENT_LAG event type communicate purpose, but parameter and method names a, b, and c obscure meaning, especially the deadline-like constructor argument and string-formatting override. 4. Code length: Concise, with little unnecessary code. 5. Action granularity: Each statement performs a focused action; the string concatenation is straightforward. 6. Reading flow: Conventional class layout supports natural reading, though cryptic public method names and minimal separation between package and imports reduce readability.
Run 2
Code Structure: Logically organized into fields, constructor, accessors, and an override. Nesting: Flat, with no nested control flow. Clarity of intent: The class name, field names, and event type convey purpose, but constructor parameters a/b/c and methods a()/b()/c() obscure meaning, particularly the overridden string method. Code length: Concise, without unnecessary logic or duplication. Action granularity: Each statement performs one clear action; the string concatenation is cohesive. Reading flow: The declaration-to-construction-to-accessor sequence is natural, though cryptic method names and the lack of spacing between package and import sections reduce readability.
Run 3
Code Structure: Logically organized into fields, constructor, accessors, and an overridden method. Nesting: Flat and easy to follow, with no nested control flow. Clarity of intent: The class and field names communicate purpose, but parameters a, b, c and methods a(), b(), c() obscure meaning, particularly the long parameter and overridden method. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear action; the string concatenation remains manageable. Reading flow: Conventional Java ordering supports natural reading, though cryptic naming forces readers to infer behavior from types and implementations.