Source code
package org.apache.kafka.clients.admin;
import org.apache.kafka.common.annotation.InterfaceAudience;
import java.util.Collection;
/**
* Options for {@link Admin#alterClientQuotas(Collection, AlterClientQuotasOptions)}.
*/
@InterfaceAudience.Public
public class AlterClientQuotasOptions extends AbstractOptions<AlterClientQuotasOptions> {
private boolean validateOnly = false;
/**
* Returns whether the request should be validated without altering the configs.
*/
public boolean validateOnly() {
return this.validateOnly;
}
/**
* Sets whether the request should be validated without altering the configs.
*/
public AlterClientQuotasOptions validateOnly(boolean validateOnly) {
this.validateOnly = validateOnly;
return this;
}
}
Run 1
The code is well-structured and highly readable. It follows a clear class definition pattern with a single private field, a getter-like method, and a fluent setter. The nesting is flat, with no conditional or loop structures. Intent is explicit through descriptive method names and Javadoc comments. The code is concise, containing only essential logic without redundancy. Each method performs one clear action. The reading flow is natural, moving from field declaration to accessor to mutator. Minor deductions relate to the lack of null checks or validation (though not required for a boolean) and the absence of additional documentation for edge cases, but overall this is exemplary, idiomatic Java code.
Run 2
The code is highly readable. It follows a clear, logical structure with a package declaration, import statements, class Javadoc, and a well-organized class body. There is minimal nesting, and the class has a single responsibility (configuring options for altering client quotas). The intent is explicit through meaningful method and variable names (`validateOnly`), and Javadoc comments clarify purpose. Code length is appropriate and concise, with one action per line in the methods. Reading flow is natural: field declaration, getter, setter. The fluent setter returns `this` and is consistent with Kafka's options pattern. Minor room for improvement could be using `isValidateOnly()` for boolean getter naming convention, but this is a Kafka-specific style.
Run 3
The code is highly readable. It follows a clear, logical structure with proper package and import organization. The class is flat with minimal nesting, and each method has a single, well-defined purpose. The Javadoc comments clearly explain the intent of both the class and its methods. The builder pattern (returning 'this') is implemented concisely and consistently. Variable naming is descriptive, and the code avoids unnecessary complexity or verbosity. Reading flow is natural, with fields, getters, and setters in conventional order.
Run 1
Code Structure: The class is logically organized, with one field followed by its getter and fluent setter. Nesting: Methods are flat and contain no nested control flow. Clarity of intent: Descriptive class and method names, the Admin API link, and method documentation make the purpose clear; however, 'configs' is slightly imprecise for client quotas. Code length: The implementation is concise, with no unnecessary logic. Action granularity: Each statement performs one action on its own line. Reading flow: The field-to-getter-to-setter sequence is natural and consistent. Minor formatting improvements, such as separating the package declaration from imports, would improve presentation.
Run 2
Code Structure: Clearly organized as a small options class with one field, a getter, and a fluent setter. Nesting: Minimal, with no conditionals or nested control flow. Clarity of intent: Descriptive class and method names plus concise documentation make the validation-only behavior explicit; however, referring to 'configs' rather than quotas slightly reduces precision. Code length: Compact and appropriate, with no unnecessary logic. Action granularity: Each statement performs a single action on its own line. Reading flow: Natural progression from class declaration to state and accessors. Minor formatting improvements, such as separating the package declaration from imports, would improve readability further.
Run 3
Code Structure: A logically organized options class with a field, getter, and fluent setter. Nesting: Minimal nesting, with simple method bodies. Clarity of intent: Descriptive names and Javadoc clearly explain validation-only behavior, though 'configs' is less precise than 'client quotas.' Code length: Concise, with no unnecessary logic; the explicit false initialization is slightly redundant. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from state to access and modification; separating the package declaration and import groups with blank lines would improve presentation.