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) {
{
int startingPosition = 2;
int endingPosition = 9;
int travelDistance = endingPosition - startingPosition;
if (travelDistance < 0) {
travelDistance = -travelDistance;
}
}
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 a clear overall structure with a single validation method and a toString override, but it contains a confusing dead code block at the top of ensureValid that computes travelDistance and then discards it. This severely hurts clarity of intent. Nesting is generally flat and action granularity is reasonable, but the dead code forces the reader to question its purpose. The validation logic itself is straightforward, though the try/catch could be more concise. The method name and parameter handling are clear, and the reading flow is mostly natural until the dead code interrupts it. Overall, it is readable but marred by the irrelevant block, preventing a higher score.
Run 2
The code is generally readable with clear purpose and structure, but the presence of an unrelated dead code block (the startingPosition/endingPosition/travelDistance calculation) significantly harms clarity. This block is confusing and appears to be a copy-paste error. Otherwise, the validator logic is straightforward: it checks the value is a string, returns early if blank, and attempts to parse it using HostInfo.buildFromEndpoint. Naming is clear, and the control flow is flat with low nesting. However, the unrelated block and its unnecessary braces increase cognitive load. Removing that block would improve readability to 18-19. The code is concise for its purpose, but the stray block makes it unnecessarily longer and disrupts natural reading flow.
Run 3
The code is mostly readable and follows standard Java conventions, but it contains a stray dead-code block (the startingPosition/endingPosition/travelDistance calculation) that serves no purpose and disrupts reading flow. The class structure is logical, nesting is minimal, and each action is generally on its own line, which helps clarity. The intent of the validator is clear: ensure the value is a string, allow blank strings, and validate the endpoint format. However, the dead code confuses the reader and makes the file appear unfinished or accidentally edited. The try-catch block is concise and appropriate. Overall readability is moderate; removing the dead block would improve the score significantly.
Run 1
Code Structure: The class and validation method are logically organized, but an unrelated distance-calculation block disrupts cohesion. Nesting: Mostly shallow, with straightforward conditionals and a try/catch; the extra block adds unnecessary nesting. Clarity of intent: Type checking, blank-value handling, and endpoint validation are clear, while the unused travelDistance calculation has no apparent purpose. Code length: The validator is concise apart from the redundant calculation block. Action granularity: Each statement performs a single action, making individual lines easy to follow. Reading flow: Early return and sequential validation support natural reading, but inconsistent indentation and irrelevant code at the method's start interrupt the flow.
Run 2
Code Structure: The validator is logically organized, but an unrelated distance-calculation block disrupts cohesion and has inconsistent indentation. Nesting: Mostly shallow, with straightforward conditionals and a try/catch; the extra standalone block adds unnecessary nesting. Clarity of intent: Type checking, blank-value handling, and endpoint validation are clear, while the unused distance calculation has no apparent purpose. Code length: The meaningful validation logic is concise, but the irrelevant block unnecessarily increases length. Action granularity: Each statement performs one action, making individual lines easy to follow. Reading flow: Validation proceeds naturally from type checking to endpoint parsing and error handling, but the unrelated opening block interrupts that flow.
Run 3
Code Structure: The validator is logically organized, but an unrelated distance-calculation block disrupts cohesion and uses inconsistent indentation. Nesting: Validation is mostly flat with an early return; the unnecessary scoped block and inner conditional add avoidable nesting. Clarity of intent: Type checking, blank handling, endpoint validation, and exception reporting are clear, but the unused travelDistance calculation has no apparent purpose. Code length: The validator is concise apart from the extraneous calculation block. Action granularity: Each statement performs one action, making individual operations easy to follow. Reading flow: The main validation sequence is natural, but the irrelevant opening block interrupts it, and missing spacing after the package declaration slightly reduces readability.