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 highly unreadable due to severe formatting issues that violate several criteria. The structure is tangled with methods, Javadoc comments, and fields compressed onto single lines, creating multiple actions per line and breaking the natural reading flow. For example, the field declaration 'private boolean validateOnly = false;' shares a line with the start of a Javadoc comment and method, and the closing braces of methods are followed immediately by comments on the same line. Nesting is not a major issue as the class is flat, but the clarity of intent is obscured because the compressed layout makes scanning difficult. While the code is technically concise, it is unnecessarily compressed, sacrificing readability for brevity. The action granularity is poor, as multiple logical actions (field declaration, comment, method signature) are packed together. The reading flow is severely disorganized, requiring the reader to mentally separate tangled elements. Overall, the code is difficult to parse and maintain despite its simple functionality.
Run 2
The code structure is severely compromised by poor formatting and layout. The class definition begins reasonably with package, import, and Javadoc, but the method declarations and inline comments are mashed together without proper line breaks. Nesting is minimal, which is a positive, but clarity of intent is undermined by comments being placed on the same line as code and methods ending abruptly. Code length is concise but at the cost of readability. Action granularity is violated: multiple actions (Javadoc, method signature, return, field declaration) appear on single lines. Reading flow is completely disorganized, forcing the reader to mentally parse dense, non-standard formatting. While the underlying logic is simple, the physical presentation makes the code nearly unreadable and difficult to maintain.
Run 3
The code is syntactically valid but poorly formatted. The major issue is readability: multiple declarations and doc comments are crammed onto single lines or merged awkwardly. This breaks all conventional Java style guides and makes the code difficult to scan. The class structure is simple, and the logic is trivial, but the layout defeats clarity. The field declaration is followed by a method comment on the same line, and the method itself begins on that same line. The javadoc for the setter is placed directly before the method signature with no line break. This hurts action granularity and reading flow, forcing the reader to parse dense lines. While the class intent is understandable, the presentation is more typical of minified code than maintainable source.
Run 1
Code Structure: The class logically groups a single option field with its getter and fluent setter, but cramped formatting obscures these boundaries. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names and Javadoc clearly explain validation-only behavior. Code length: Concise and appropriate for a simple options class. Action granularity: Method statements generally remain separate, but multiple imports share a line, and comments and braces are crowded onto adjacent declarations or statements. Reading flow: The field-to-getter-to-setter sequence is natural, but inconsistent line breaks and inline closing braces interrupt scanning. Conventional formatting would substantially improve readability.
Run 2
Code Structure: The class logically groups a single option with its getter and fluent setter, but cramped formatting weakens visual separation. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names and Javadoc clearly explain validation-only behavior, though 'configs' is less precise than 'client quotas.' Code length: Appropriately short, with no unnecessary logic. Action granularity: Method bodies contain simple individual actions, but multiple imports share a line, and declarations, comments, and braces are crowded together. Reading flow: The getter-to-setter progression is natural, but inconsistent line breaks and comments attached to preceding statements interrupt scanning.
Run 3
Code Structure: The class logically groups a single option with its getter and fluent setter, but inconsistent formatting weakens organization. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names and Javadoc clearly explain validation-only behavior, though referring to configs rather than quotas is slightly imprecise. Code length: The implementation is concise without unnecessary logic. Action granularity: Imports share a line, and declarations, statements, braces, and comments are crowded together rather than consistently separated. Reading flow: The sequence is natural, but comments attached to preceding code and irregular brace placement interrupt scanning.