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 a(final String a, final Object b) {
if (!(b instanceof String)) {
throw new ConfigException(a + " must be a string");
}
final String c = (String) b;
if (Utils.isBlank(c)) {
return;
}
try {
HostInfo.buildFromEndpoint(c);
} catch (final ConfigException d) {
throw new ConfigException(a, b, d.getMessage());
}
}
@Override
public String b() {
return "A host:port pair, protocol://host:port, or an empty string";
}
}
Run 1
The code has a clear purpose, but readability is hampered by poor naming conventions. Method names 'a' and 'b' obscure intent, and parameters 'a' and 'b' are equally vague. The structure is mostly flat with low nesting, which is good, but the action granularity and flow are mixed. The try-catch block is concise but could clarify the error message with a specific prefix. The blank string return is acceptable but does not explain why it's allowed. The code length is reasonable, but renaming methods and parameters (e.g., 'validate' and 'toString') would dramatically improve clarity. The import list is tidy, and the class's single responsibility is clear, though the overall logic would benefit from more descriptive identifiers to convey intent without extra comments.
Run 2
The code is heavily obfuscated. Parameter and variable names (a, b, c, d) and method names (a, b) are entirely non-descriptive, making intent impossible to infer without deep analysis. The logic is otherwise structurally simple and flat, but the naming destroys clarity of intent and readability. Renaming elements to meaningful identifiers (e.g., validate(name, value), toString(), endpoint, exception) would make this a reasonably clear validator. As presented, it reads like decompiled or intentionally minified code, violating nearly every readability criterion except basic structure and length. Action granularity is acceptable, and nesting is minimal, but reading flow and clarity of intent are severely compromised by the meaningless identifiers.
Run 3
The code is terse and obfuscated due to poor naming (parameters a, b; local c; exception d), which obscures intent. The structure is logical but access modifiers and imports make it unclear if this is a test or production class. Nesting is minimal and action granularity is acceptable, but the generic parameter names and method name b() harm clarity and reading flow. The logic is concise but sacrifices readability.
Run 1
Code Structure: Well organized into a validation method and a description method, with imports and a descriptive class name. Nesting: Shallow conditionals and a simple try-catch; the early return keeps the flow flat. Clarity of intent: Type checking, blank-value handling, and endpoint validation are understandable, but single-letter method and variable names obscure roles and reduce readability. Code length: Concise without unnecessary logic or repetition. Action granularity: Each statement performs one clear action, with no crowded lines. Reading flow: Validation proceeds naturally from type checking to blank handling to endpoint parsing and exception wrapping. Missing spacing after the package declaration is a minor formatting issue.
Run 2
Code Structure: The validator is logically organized into type checking, blank-value handling, endpoint validation, and a descriptive string method. Nesting: Shallow conditionals and an early return keep the code easy to follow. Clarity of intent: The class name, exception messages, and library calls reveal the purpose, but method names a/b and variables a/b/c/d obscure roles and reduce readability substantially. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each statement performs a single clear action. Reading flow: Validation proceeds naturally from basic checks to parsing and error handling, though cryptic identifiers interrupt comprehension.
Run 3
Code Structure: The class is logically organized into validation and descriptive methods, with imports grouped at the top. Nesting: Shallow conditionals, an early return, and a simple try/catch keep complexity low. Clarity of intent: The class name, exception messages, and endpoint parser reveal the purpose, but method names a/b and variable names a/b/c/d obscure roles and reduce readability substantially. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one action, making individual steps easy to follow. Reading flow: Validation proceeds naturally from type checking to blank handling to endpoint parsing, though cryptic identifiers interrupt comprehension.