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 ensureValid(final String name, final Object value) {
if (!((!(value instanceof String)))) {} else {
throw new ConfigException(name + " must be a string");
}
final String endPoint = (String) value;
if (!((Utils.isBlank(endPoint)))) {} else {
return;
}
try {
HostInfo.buildFromEndpoint(endPoint);
} catch (final ConfigException e) {
throw new ConfigException(name, value, e.getMessage());
}
}
@Override
public String toString() {
return "A host:port pair, protocol://host:port, or an empty string";
}
}
Run 1
The code has severe readability issues. The use of double negatives in conditions like `if (!((!(value instanceof String))))` makes the logic difficult to follow. Empty if-blocks with else-statements that contain the actual logic reverse the natural reading flow. The validation logic could be expressed much more directly with early returns and positive conditions. The action granularity is inconsistent, with multiple operations packed into some lines. While the class has a clear purpose and the method is relatively short, the confusing conditional structure and unnatural control flow significantly reduce readability. The toString method is clear, and the code is concise, but the core validation logic needs restructuring for clarity.
Run 2
The code demonstrates poor readability due to several structural and logical issues. It uses inverted conditional expressions with empty if-blocks (e.g., `if (!(condition)) {} else { ... }`) instead of direct positive checks, making intent unclear. The nesting is minimal but the control flow is convoluted. Multiple actions are crammed into single lines, violating action granularity principles. The variable naming is inconsistent ('endPoint' vs standard 'endpoint'), and the validation logic sequence (type check, blank check, endpoint parsing) lacks clear separation. The toString method is straightforward but the overall reading flow feels unnatural and requires mental gymnastics to understand. The code would benefit from early-return patterns, positive conditionals, and more descriptive structure.
Run 3
The code is severely unreadable due to convoluted conditional logic using negated double negatives with empty branches (e.g., `if (!((!(value instanceof String)))) {} else { ... }`). This creates confusing, non-idiomatic control flow that obscures intent. Nesting is minimal but the structure is poor. The logic for string validation and blank checks could be expressed much more clearly and concisely. Reading flow is disrupted by the awkward conditionals. While the code is functionally short, it sacrifices clarity for brevity. The intent is discernible only after mental parsing of the double negatives. Action granularity is adequate but overall quality is severely compromised by the hostile conditionals.
Run 1
Code Structure: The class is logically organized around validation and a descriptive toString method, but empty conditional branches undermine the structure. Nesting: Nesting is shallow, though excessive parentheses and negations add cognitive complexity. Clarity of intent: Endpoint validation is recognizable, but the type check is counterintuitive: it throws for String values and lets non-strings reach the cast, suggesting inverted logic. Code length: The implementation is short, but unnecessarily elaborate conditionals could be replaced with straightforward guards. Action granularity: Most statements perform one action, although the compact empty-if/else formatting reduces readability. Reading flow: Imports, validation, parsing, and exception handling follow a natural sequence, but readers must decode double negations and empty branches before understanding control flow.
Run 2
Code Structure: The validator is logically organized into type checking, blank handling, and endpoint validation, but empty branches obscure that structure. Nesting: Depth is shallow, although redundant parentheses, negations, and else branches add cognitive complexity. Clarity of intent: Class and method names communicate the purpose, but the type check is inverted: strings throw an exception while non-strings proceed to a cast, contradicting the intended validation. Code length: The implementation is short, but unnecessarily elaborate conditionals reduce concision. Action granularity: Statements generally perform one action each, though inline empty branches impair scanning. Reading flow: Validation follows a natural sequence, but readers must untangle Boolean expressions and reconcile the type-check behavior with the error message.
Run 3
Code Structure: The validator is logically organized into type checking, blank handling, and endpoint validation, but empty if branches with logic in else blocks obscure that structure. Nesting: Depth is shallow, although redundant parentheses and negations make conditions harder to parse. Clarity of intent: Names and the descriptive toString help, but the double-negated type check actually throws for strings and allows non-strings through, contradicting the apparent intent. Code length: Short overall, with unnecessary conditional scaffolding. Action granularity: Statements generally perform one action each, though inline empty branches reduce visual clarity. Reading flow: Validation proceeds in a natural sequence, but inverted conditions and empty branches interrupt straightforward reading.