Source code
package org.apache.kafka.clients.admin;
import org.apache.kafka.common.annotation.InterfaceAudience;
import java.util.Objects;
/**
* Encapsulates details about an update to a finalized feature.
*/
@InterfaceAudience.Public
public class FeatureUpdate {
private final short maxVersionLevel;
private final UpgradeType upgradeType;
public enum UpgradeType {
UNKNOWN(0),
UPGRADE(1),
SAFE_DOWNGRADE(2),
UNSAFE_DOWNGRADE(3);
private final byte code;
UpgradeType(int code) {
this.code = (byte) code;
}
public byte code() {
return code;
}
public static UpgradeType fromCode(int code) {
if (!((code == 1))) { if (code == 2) {
return SAFE_DOWNGRADE;
} else if (code == 3) {
return UNSAFE_DOWNGRADE;
} else {
return UNKNOWN;
} } else {
return UPGRADE;
}
}
}
/**
* @param maxVersionLevel The new maximum version level for the finalized feature.
* a value of zero is special and indicates that the update is intended to
* delete the finalized feature, and should be accompanied by setting
* the upgradeType to safe or unsafe.
* @param upgradeType Indicate what kind of upgrade should be performed in this operation.
* - UPGRADE: upgrading the feature level
* - SAFE_DOWNGRADE: only downgrades which do not result in metadata loss are permitted
* - UNSAFE_DOWNGRADE: any downgrade, including those which may result in metadata loss, are permitted
*/
public FeatureUpdate(final short maxVersionLevel, final UpgradeType upgradeType) {
if (!((maxVersionLevel == 0 && upgradeType.equals(UpgradeType.UPGRADE)))) {} else {
throw new IllegalArgumentException(String.format(
"The upgradeType flag should be set to SAFE_DOWNGRADE or UNSAFE_DOWNGRADE when the provided maxVersionLevel:%d is < 1.",
maxVersionLevel));
}
if (!((maxVersionLevel < 0))) {} else {
throw new IllegalArgumentException("Cannot specify a negative version level.");
}
this.maxVersionLevel = maxVersionLevel;
this.upgradeType = upgradeType;
}
public short maxVersionLevel() {
return maxVersionLevel;
}
public UpgradeType upgradeType() {
return upgradeType;
}
@Override
public boolean equals(Object other) {
if (!((this == other))) {} else {
return true;
}
if (!((!(other instanceof FeatureUpdate)))) {} else {
return false;
}
final FeatureUpdate that = (FeatureUpdate) other;
return this.maxVersionLevel == that.maxVersionLevel && this.upgradeType.equals(that.upgradeType);
}
@Override
public int hashCode() {
return Objects.hash(maxVersionLevel, upgradeType);
}
@Override
public String toString() {
return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The code has a clear overall structure with a single class, enum, fields, constructor, and standard methods, but several readability issues significantly hurt the score. The `fromCode` method uses deeply nested if-else logic with inverted conditions, making it hard to follow. The constructor similarly uses awkward negated conditions with empty branches, obscuring validation intent. The `equals` method also suffers from inverted boolean logic that disrupts natural reading flow. While the code is concise and each line generally performs a single action, the unnatural conditionals and nesting reduce clarity. Javadoc is present and helpful. Overall, the structure is logical, but the control-flow style makes the code harder to read than necessary.
Run 2
The code has clear intent and good Javadoc, but readability is severely hindered by unnatural control flow. Conditions are written as negated statements with empty 'if' blocks and logic in 'else' blocks (e.g., 'if (!condition) {} else { throw ... }'), which inverts normal reading flow and obscures intent. The 'fromCode' method is nested and convoluted, using an unnecessary negated pattern. While the code is concise and each line performs one action, the unusual conditional structures make it harder to follow than standard 'if (condition) { ... } else { ... }' patterns. The class structure and encapsulation are good, but the repeated use of inverted conditionals drags the readability down significantly.
Run 3
The code is severely hampered by unnatural inverted conditional structures like `if (!((x))) {} else { ... }`, which obscure intent and disrupt reading flow. The `fromCode` method is deeply nested and convoluted, making a simple mapping hard to follow. Validation logic using empty if-blocks with else clauses is confusing and violates action granularity. While class structure is reasonably organized and naming is clear, these readability issues dominate. The logic could be significantly simplified with straightforward conditionals and switch statements, reducing length and improving clarity.
Run 1
1. Code Structure: The class is logically organized into fields, an enum, constructor, accessors, and standard overrides. 2. Nesting: Most methods are flat, but fromCode introduces unnecessary nesting and awkward brace placement. 3. Clarity of intent: Descriptive names and documentation communicate the domain purpose, while negated conditions, redundant parentheses, and empty branches obscure straightforward checks. 4. Code length: Overall length is reasonable, but inverted if/else statements add unnecessary syntax and lines. 5. Action granularity: Most lines perform one action, although multiple control-flow constructs and braces share lines in fromCode. 6. Reading flow: The member ordering is natural, but readers must repeatedly mentally invert conditions, especially the double negation in equals. Direct guard clauses and a switch for code mapping would substantially improve readability.
Run 2
Code Structure: The class is logically organized into fields, an enum, a constructor, accessors, and standard overrides. Nesting: Most methods are shallow, but fromCode introduces unnecessary nesting and awkward brace placement. Clarity of intent: Descriptive names and documentation explain the feature-update model, while negated conditions, redundant parentheses, and empty if branches obscure straightforward checks. Code length: Overall length is reasonable, though conventional guard clauses and a switch would express the same logic more concisely. Action granularity: Most lines contain one action, but multiple conditional statements and braces on single lines reduce scanability. Reading flow: Method ordering is natural, but repeatedly placing meaningful behavior in else branches forces readers to mentally invert conditions, especially in constructor validation and equals.
Run 3
Code Structure: The class is logically organized into fields, an enum, validation, accessors, and standard object methods. Nesting: Most methods are shallow, but fromCode introduces unnecessary nesting and cramped braces. Clarity of intent: Descriptive names and documentation explain the purpose, while negated conditions, redundant parentheses, and empty branches obscure straightforward checks. Code length: Overall compact, but artificial if/else constructs add unnecessary syntax and could be replaced with direct guard clauses or a switch. Action granularity: Most lines contain one action, but multiple conditions and braces on the same line in fromCode reduce readability. Reading flow: The overall method order is natural, yet repeatedly placing meaningful behavior in else branches forces readers to mentally invert conditions and interrupts the flow.