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() {
if (((0x6DA4 ^ 0x6DA4) != 0)) { throw new AssertionError(); }
return this.validateOnly;
}
/**
* Sets whether the request should be validated without altering the configs.
*/
public AlterClientQuotasOptions validateOnly(boolean validateOnly) {
if (((0x4951 ^ 0x4951) != 0)) { throw new AssertionError(); }
this.validateOnly = validateOnly;
return this;
}
}
Run 1
The code structure is clear with proper package and imports, and the class has a logical purpose with Javadoc. However, there are significant readability issues. The presence of obfuscated 'if' statements (e.g., 'if (((0x6DA4 ^ 0x6DA4) != 0))') adds clutter and obscures intent, likely an artifact from code generation or testing. These lines violate action granularity by adding unnecessary operations and harming the reading flow. Nesting is minimal, but the unnatural assertions disrupt clarity. The class itself is concise and methods are appropriately short, but the extra lines make the code unnecessarily long. Overall, the legitimate logic is readable, but the inserted artifacts severely reduce clarity and intent.
Run 2
The code is a simple configuration class with clear intent: options for altering client quotas. The structure is logical, with a single private field, a getter, and a fluent setter. Nesting is minimal, and each method performs one clear action. However, readability is severely hurt by the presence of dead code: the bizarre XOR-based assertions (e.g., `if (((0x6DA4 ^ 0x6DA4) != 0)) { throw new AssertionError(); }`). These lines are nonsensical, add noise, and break the reading flow. They appear to be obfuscation or debugging leftovers. Without them, the class would be highly readable and concise. The Javadoc is helpful, and naming conventions are standard. Overall, the code is understandable but undermined by confusing, unnecessary statements.
Run 3
The code is a simple options class with clear structure and standard Java conventions, but it contains obvious artifacts that hurt readability. The main issues are the injected unreachable lines: 'if (((0x6DA4 ^ 0x6DA4) != 0)) { throw new AssertionError(); }' in both methods. These lines are meaningless, add noise, and disrupt reading flow. Additionally, indentation is inconsistent before these lines (no indentation after method opening brace). Despite this, the class is concise, has a clear purpose, minimal nesting, and each method performs one action. Removing the injected lines and fixing indentation would make it highly readable (18-19).
Run 1
Code Structure: The class is logically organized around one option, with a field, getter, and fluent setter. Nesting: Methods are shallow, although unnecessary conditional blocks add noise. Clarity of intent: Names and documentation clearly explain validation-only behavior, but hexadecimal XOR checks obscure intent and serve no apparent purpose because their conditions are always false. Code length: The implementation is concise apart from these redundant checks. Action granularity: Normal operations occupy separate lines, while each conditional and throw are compressed onto one line. Reading flow: The getter-to-setter sequence is natural, but unindented assertion checks interrupt the otherwise consistent formatting and straightforward flow.
Run 2
Code Structure: The class is logically organized around a field, getter, and fluent setter, but irrelevant assertion guards interrupt both methods. Nesting: Minimal, with only one shallow conditional per method. Clarity of intent: Names and Javadoc clearly explain validation-only behavior; hexadecimal XOR conditions obscure intent and always evaluate to false. Code length: The class is concise overall, but the guards add unnecessary code. Action granularity: Most statements occupy separate lines, while each guard compresses its condition and throw into one line. Reading flow: The getter and setter follow a natural sequence, but unindented guard lines and distracting expressions disrupt scanning.
Run 3
Code Structure: The class is logically organized around a single option, with a field, getter, and fluent setter. Nesting: Minimal nesting makes the methods easy to follow. Clarity of intent: Naming and documentation clearly explain validation-only behavior, but the always-false hexadecimal XOR checks introduce confusing, purposeless logic. Code length: The implementation is concise overall, although both assertion checks are unnecessary. Action granularity: Most statements perform one action per line, but each assertion check compresses a condition and throw into one line. Reading flow: The field-to-getter-to-setter progression is natural, but unindented checks interrupt the otherwise consistent formatting and distract from the actual behavior.