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. Structure is logical with clear separation of fields and methods. Nesting is flat—no conditional or loop nesting. Intent is unambiguous: a simple options class with a fluent 'validateOnly' flag. Code length is minimal and appropriate. Each line performs a distinct action, and reading flow follows Java conventions (field, getter, setter, builder-style return). Javadoc and annotations enhance clarity without clutter.
Run 3
The code demonstrates excellent readability. It starts with a clear package and a minimal import section. The class-level Javadoc precisely explains its purpose with a direct link to the relevant Admin API method. The class extends a clearly named AbstractOptions class, indicating a builder pattern. The single field `validateOnly` has a descriptive name and a sensible default. The getter method `validateOnly()` and the setter method `validateOnly(boolean)` are well-named and follow a fluent API style by returning `this`. Javadoc comments on both methods clearly distinguish between querying and configuring the validation behavior. The structure is flat, each method contains a single action, and the overall length is very concise. The only minor deduction is the lack of an explicit constructor, though the default constructor is perfectly sufficient for this use case.
Run 1
Code Structure: The class is logically organized, with one option field followed by its getter and fluent setter. Nesting: Methods are flat, with no conditional or loop nesting. Clarity of intent: Descriptive names, the class-level API link, and method documentation clearly communicate purpose; however, 'configs' is slightly less precise than 'client quotas.' Code length: The implementation is concise, with no unnecessary logic. Action granularity: Each statement performs one action, and assignment and return are on separate lines. Reading flow: The progression from field to getter to setter is natural and easy to follow. Minor formatting improvements, such as separating the package declaration from imports, would improve visual organization.
Run 2
Code Structure: A logically organized options class with a single field, getter, and fluent setter. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and Javadoc make validation-only behavior clear, though 'configs' is less precise than 'client quotas.' Code length: Concise, with no unnecessary logic; explicit initialization to false is slightly redundant. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from state to access and mutation, with consistent formatting; separating the package declaration from imports would improve presentation.
Run 3
Code Structure: Logically organized as a small options class with a field, getter, and fluent setter. Nesting: Flat, with no conditional branches or nested control flow. Clarity of intent: Descriptive naming and Javadoc clearly explain validation-only behavior, though 'configs' is slightly imprecise for client quotas. Code length: Concise, with no unnecessary complexity. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from state to access and modification; additional spacing around the package and import sections would slightly improve presentation.