Sample

int-bfadb4c3952c-SRC

Unmodified source class

Lines60

Scores

MethodScoreScale
Posnett0.8850–1; higher is more readable
Scalabrino0.8250–1; higher is more readable
Dorn0.5780–1; higher is more readable
Mi0.1160–1; higher is more readable
LLOC5Logical lines; fewer is more readable
DeepSeek V4 Pro17.670–20; mean of three runs
GPT-6.1 Sol180–20; mean of three runs
BTTF0.7260–1; higher is more readable

Views

Source code

package org.apache.kafka.connect.connector.policy; import org.apache.kafka.common.Configurable; import org.apache.kafka.common.annotation.InterfaceAudience; import org.apache.kafka.common.config.ConfigDef; import org.apache.kafka.common.config.ConfigValue; import org.apache.kafka.connect.components.ConnectPlugin; import java.util.List; /** * An interface for enforcing a policy on overriding of Kafka client configs via the connector configs. * <p> * Common use cases are ability to provide principal per connector, <code>sasl.jaas.config</code> * and/or enforcing that the producer/consumer configurations for optimizations are within acceptable ranges. * <p>Kafka Connect discovers implementations of this interface using the Java {@link java.util.ServiceLoader} mechanism. * To support this, implementations of this interface should also contain a service provider configuration file in * {@code META-INF/services/org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy}. * <p> * Implement {@link org.apache.kafka.common.metrics.Monitorable} to enable the policy to register metrics. * The following tags are automatically added to all metrics registered: <code>config</code> set to * <code>connector.client.config.override.policy</code>, and <code>class</code> set to the * ConnectorClientConfigOverridePolicy class name. */ @InterfaceAudience.Public public interface ConnectorClientConfigOverridePolicy extends Configurable, AutoCloseable, ConnectPlugin { /** * Workers will invoke this before configuring per-connector Kafka admin, producer, and consumer client instances * to validate if all the overridden client configurations are allowed per the policy implementation. * This would also be invoked during the validation of connector configs via the REST API. * <p> * If there are any policy violations, the connector will not be started. * * @param connectorClientConfigRequest an instance of {@link ConnectorClientConfigRequest} that provides the configs * to be overridden and its context; never {@code null} * @return list of {@link ConfigValue} instances that describe each client configuration in the request and includes an {@link ConfigValue#errorMessages() error} if the configuration is not allowed by the policy; never null */ List<ConfigValue> validate(ConnectorClientConfigRequest connectorClientConfigRequest); /** * Configuration specification for this policy override. * * @return the configuration definition for this policy override; never null */ @Override default ConfigDef config() { return new ConfigDef(); } /** * Get the version of this component. * * @return the version, formatted as a String. The version may not be {@code null} or empty. */ @Override default String version() { return "undefined"; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.60+24
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.724.925−23.923
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.4.604−6.907

Intercept 8.87 + feature contributions = 2.041 (log-odds).
Score = sigmoid(2.041) = 0.885.

Score0.825

Feature contributions

FeatureValueContribution
(log-odds)
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.123.967−1.586
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.121.951+1.163
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.61−1.123
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.021+0.734
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.59.864+0.427
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Indentation frequencyHow rapidly indentation changes from line to line.28+0.231

Intercept 0.07 + feature contributions = 0.315 (log-odds).
Score = sigmoid(0.315) = 0.578.

Score0.116
Score5
Run 1

The code is highly readable. It demonstrates clear structure with logical separation between the interface declaration, Javadoc, and methods. Nesting is non-existent, as expected for an interface. Intent is clearly communicated through comprehensive Javadoc, explaining the purpose, use cases, and lifecycle. The code is concise for its purpose—the verbose documentation is justified for a public Kafka API. Action granularity is appropriate: each method declaration is on its own line, and default implementations are minimal. The reading flow is natural, starting with the interface overview, moving to the primary 'validate' method, and ending with inherited framework methods. Minor deductions are for slightly long return type documentation in the Javadoc, which wraps awkwardly, and the interface extends four other interfaces, which slightly increases cognitive load upfront. Overall, this is exemplary of well-documented, maintainable Java interface code.

Run 2

The code is highly readable due to its clear logical structure and purpose. The interface is well-organized, with imports neatly grouped and Javadoc thoroughly explaining the contract, usage, and discovery mechanism. Nesting is non-existent since this is an interface with only two methods and two default implementations. Intent is unambiguous—every method and parameter is documented, and the naming is descriptive. Code length is appropriate for an API definition; it is concise without omitting critical documentation. Action granularity is excellent, with each method and default implementation separated naturally. Reading flow is logical, progressing from interface declaration to validation logic to configuration metadata. The only minor drawback is slightly verbose Javadoc, which could be considered excessive for simple default methods, but this does not significantly hinder readability. Overall, this is exemplary API code.

Run 3

The code is well-structured and readable. It starts with clear package and import declarations, followed by comprehensive Javadoc that explains the interface's purpose, usage, and discovery mechanism. The interface definition is straightforward, extending logical interfaces. The method validate() has a clear signature and descriptive Javadoc, though the return tag formatting is slightly misaligned. Default methods config() and version() are concise and self-documenting. Nesting is non-existent, and action granularity is appropriate. The reading flow is natural, with a logical progression from purpose to methods. Minor deductions: the long Javadoc paragraph about ServiceLoader could be broken up, and the import list is slightly long but necessary. Overall, the code demonstrates high readability with clear intent and minimal complexity.

Run 1

Code Structure: The interface is logically organized, with imports, interface documentation, validation, configuration, and version methods clearly separated. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and thorough Javadoc explain the policy's purpose, lifecycle, and method contracts; the default version value is somewhat uninformative. Code length: The implementation is concise, though documentation dominates and could be tightened slightly. Action granularity: Each method declaration or return statement occupies its own line, with no bundled actions. Reading flow: The top-to-bottom progression is natural. Minor formatting issues—extra blank lines, ungrouped imports, and inconsistent indentation in the return documentation—slightly reduce polish without obstructing understanding.

Run 2

Code Structure: The interface logically groups validation, configuration, and version methods, with clear annotations and documentation. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadocs explain the policy's purpose, integration, and validation contract. Code length: The implementation is concise, though documentation dominates and contains some wordy phrasing. Action granularity: Each declaration and return statement occupies its own line; no actions are combined. Reading flow: The progression from interface documentation to method contracts and simple defaults is natural. Minor distractions include extra blank lines, inconsistent Javadoc indentation, and imports without visual grouping.

Run 3

Code Structure: Logically organized interface with imports, class documentation, and clearly separated methods. Nesting: Minimal nesting; default methods contain single return statements. Clarity of intent: Descriptive names and comprehensive Javadoc explain policy validation, configuration, and version behavior. Code length: Implementation is concise, though documentation is somewhat verbose relative to the small interface. Action granularity: Each statement performs one action, with no compressed or compound operations. Reading flow: Natural progression from interface purpose to validation and default metadata methods. Minor readability issues include extra blank lines, inconsistent Javadoc continuation formatting, long documentation lines, and slightly awkward wording.