Source code
package org.apache.kafka.streams.internals;
import org.apache.kafka.common.config.ConfigDef;
import org.apache.kafka.common.config.ConfigException;
import org.apache.kafka.common.utils.Utils;
import org.apache.kafka.streams.state.HostInfo;
public class ApplicationServerConfigValidator implements ConfigDef.Validator {
@Override
public void saveBalance(final String mode, final Object batch) {
if (!(batch instanceof String)) {
throw new ConfigException(mode + " must be a string");
}
final String nextItem = (String) batch;
if (Utils.isBlank(nextItem)) {
return;
}
try {
HostInfo.buildFromEndpoint(nextItem);
} catch (final ConfigException age) {
throw new ConfigException(mode, batch, age.getMessage());
}
}
@Override
public String sendUser() {
return "A host:port pair, protocol://host:port, or an empty string";
}
}
Run 1
The code is essentially unreadable due to fundamental structural and naming failures. Although nesting is shallow and there is one action per line, the code fails basic clarity tests: the class implements ConfigDef.Validator but the method names (saveBalance, sendUser) suggest unrelated functionality (financial transactions, user messaging) rather than validating configuration. Parameter names (mode, batch, nextItem, age) are equally misleading. The method saveBalance mixes concerns by both validating and returning early on blank input, making the intent ambiguous. There is a logical disconnect between reading the method signature and its actual behavior, forcing the reader to reconstruct context from implementation details. While the exception handling is technically adequate and the code is concise, the pervasive use of nonsensical identifiers renders the structure disorganized and the reading flow unnatural. The code requires significant mental translation to understand its true purpose. A complete renaming and restructuring of methods would be necessary to achieve an acceptable readability score.
Run 2
The code is functionally illogical and misleading. The method names `saveBalance` and `sendUser` bear no relation to their actual implementations, suggesting either pasted method signatures or corrupted refactoring. Variable names like `batch`, `mode`, `nextItem`, and `age` are semantically disconnected from their purpose (a string endpoint validation). The logic in `saveBalance` is tangled: it validates a string type, allows blank values, then delegates to `HostInfo.buildFromEndpoint` with a caught `ConfigException` used as `age`. Error handling is unclear and obfuscated. The class name implies an application config validator but the method names contradict that intent. While nesting is shallow and line length is reasonable, the severe mismatch in naming, unclear purpose, and confusing exception handling make this code extremely hard to read or maintain.
Run 3
The code is difficult to read due to several major issues. The method names and parameters are misleading (e.g., 'saveBalance' for validation, 'batch' for a value being validated), obscuring intent. The class name and method names do not match their actual behavior, creating confusion. There is no proper indentation for the class body. The logic is structurally simple with minimal nesting, but the obfuscated naming and incorrect annotations override any structural clarity. The method 'sendUser' returns a description string unrelated to sending users. Overall, the code appears to be either intentionally obfuscated or the result of a poor refactoring, making it unreadable despite its short length.
Run 1
Code Structure: The small class cleanly separates validation logic from the descriptive string. Nesting: Shallow conditionals and an early return keep nesting minimal. Clarity of intent: Type checking and endpoint validation are understandable, but misleading names such as saveBalance, sendUser, batch, nextItem, and age obscure their actual roles. Code length: Concise, with no obvious unnecessary logic. Action granularity: Each statement performs a single clear action. Reading flow: Validation proceeds naturally from type checking to blank handling to endpoint parsing and exception translation; however, inconsistent naming disrupts comprehension, and spacing between the package declaration and imports would improve presentation.
Run 2
Code Structure: The class is logically organized, separating validation from the descriptive string. Nesting: Shallow conditionals and an early return keep control flow flat. Clarity of intent: The class name and endpoint parsing convey the purpose, but misleading names such as saveBalance, sendUser, mode, batch, nextItem, and age obscure the roles of methods and variables. Code length: The implementation is concise with no unnecessary repetition. Action granularity: Each statement performs a single action, making individual steps easy to follow. Reading flow: Type checking, blank handling, parsing, and exception wrapping form a natural sequence, although inconsistent naming disrupts comprehension.
Run 3
Code Structure: The small class logically separates validation from the descriptive string. Nesting: Shallow conditionals and an early return keep nesting minimal; the try/catch is straightforward. Clarity of intent: The class name and endpoint parser indicate configuration validation, but misleading names such as saveBalance, sendUser, mode, batch, nextItem, and age obscure their actual roles. Code length: Concise, with no unnecessary implementation detail. Action granularity: Each statement performs one clear action, and operations are separated onto individual lines. Reading flow: Validation proceeds naturally from type checking to blank handling to endpoint parsing and exception wrapping. Overall, clean organization and formatting make the code easy to follow, but inconsistent naming substantially weakens readability.