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)) {
throw new ConfigException(name + " must be a string"); }
final String endPoint = (String) value; if (Utils.isBlank(endPoint)) { 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 serious readability issues. The package and multiple imports are crammed onto one line, breaking convention. The method bodies are not properly formatted—opening braces appear on the same line as conditions and closing braces are collapsed together, making the structure hard to follow. Nesting is shallow, which is good, but action granularity and reading flow suffer due to multiple statements sharing lines. Intent is somewhat clear (validate endpoint strings), but the messy formatting obscures logic. The toString method is overly compact with poor line breaks. Overall, the code requires significant reformatting to be considered maintainable or readable.
Run 2
The code is heavily obfuscated by poor formatting: multiple statements on single lines, inconsistent line breaks, and braces positioned abruptly. While the underlying logic is simple (validate string, optionally parse endpoint, provide description), the presentation severely hampers readability. Nesting is mild (one if, one try-catch), but the compressed layout obscures it. Intent is inferable but not clearly expressed due to formatting. Code length is short, but brevity is achieved through unreadable cramming rather than concise design. Action granularity is violated with multiple actions per line. Reading flow is unnatural and disorganized. Overall, the code would require significant reformatting before a maintainer could readily scan and understand it.
Run 3
The code is functionally simple but structurally confusing due to collapsed import statements, multiple statements on single lines, and inconsistent formatting. The ensureValid method combines an if block on the same line as the method signature, and the try-catch block is compressed into two lines, making it hard to distinguish logical blocks. Action granularity is violated with multiple actions per line. Nesting is shallow, which is positive, but reading flow is disorganized and unnatural. Clarity of intent is partially present, but the formatting undermines readability. Code length is concise, but at the expense of clarity. Overall, basic logic is understandable, yet the presentation is poor and would slow down a reader significantly.
Run 1
Code Structure: The validator has logically separated validation and description methods, but compressed declarations and braces obscure their boundaries. Nesting: Shallow conditionals and a simple try/catch keep complexity low. Clarity of intent: Descriptive names and explicit exceptions make the validation purpose clear. Code length: The implementation is concise without unnecessary logic, although excessive compression reduces readability. Action granularity: Several lines combine imports, declarations, conditionals, returns, or method boundaries, making individual actions harder to scan. Reading flow: Validation follows a natural sequence—check type, allow blank input, parse the endpoint, and wrap errors—but inconsistent formatting and misplaced closing braces interrupt that flow.
Run 2
Code Structure: Validation steps are logically organized within a small class, but compressed declarations and misplaced closing braces obscure method boundaries. Nesting: Shallow conditionals and a simple try/catch keep complexity low. Clarity of intent: Descriptive class and method names make endpoint validation clear, though the parsing method's validation role is implicit. Code length: Concise and free of unnecessary logic. Action granularity: Package/import declarations, variable assignment, conditionals, and annotations share lines, reducing scanability. Reading flow: The validation sequence is natural, but inconsistent formatting and crowded braces interrupt reading.
Run 3
Code Structure: The validator has a logical sequence of type checking, blank-value handling, and endpoint validation, but cramped formatting obscures method boundaries. Nesting: Shallow conditionals and a simple try-catch keep complexity low. Clarity of intent: Descriptive class and method names, explicit exceptions, and the explanatory toString make the purpose clear. Code length: Concise, with no unnecessary logic. Action granularity: Several lines combine distinct statements, including package/import declarations, assignment/conditional handling, and closing braces/annotations. Reading flow: The validation sequence is natural, but inconsistent line breaks and brace placement interrupt scanning. Conventional formatting would substantially improve readability.