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
This is a highly readable class. The structure is logical and follows standard Java conventions, with a package declaration, imports, and a clear class definition. Nesting is non-existent; the class is completely flat. Intent is crystal clear from the class name, method names, and Javadoc comments, which succinctly explain the purpose of the API and its `validateOnly` flag. The code is concise, containing no unnecessary boilerplate. Each action, such as the return statement and the assignment in the setter, occupies its own line, promoting clarity. The reading flow is natural—the Javadoc is at the top, fields are declared, and the getter precedes the setter, aligning with common expectations.
Run 3
The code is highly readable and follows clean coding principles. It has a clear structure with a single class, one field, and two well-named methods. Nesting is minimal. Intent is explicit through descriptive method and parameter names, plus Javadoc comments. Code length is concise with no redundancy. Each statement performs one action, and the fluent setter (returning 'this') follows standard Kafka Admin API conventions, aiding natural reading flow.
Run 1
Code Structure: Logically organized into a field, getter, and fluent setter. Nesting: Flat, with no nested control flow. Clarity of intent: The class name, method names, and Javadoc clearly convey the validation-only option, although 'configs' is less precise than 'client quotas.' Code length: Concise, with minimal boilerplate and no unnecessary logic. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from the class purpose to stored state and access methods; a blank line after the package declaration would slightly improve formatting.
Run 2
Code Structure: A logically organized options class with one field and adjacent getter and fluent setter. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and Javadoc clearly explain validation-only behavior; referring to 'configs' rather than client quotas is slightly imprecise. Code length: Concise, with no unnecessary logic; explicit initialization to false is mildly redundant. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from class documentation to state, getter, and setter. Minor import-spacing and ordering improvements would make the presentation more polished.
Run 3
Code Structure: A logically organized options class with one field, a getter, and a fluent setter. Nesting: Flat, with no nested control flow. 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. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from declaration to state and accessors; minor spacing improvements around the package and imports would improve presentation.