Sample

int-4210b0f8b5df-I05

Rewrite eligible decimal integer literals in hexadecimal notation

DatasetJava transformations

Lines168

Scores

Method	Score	Scale
Posnett	0.996	0–1; higher is more readable
Scalabrino	0.879	0–1; higher is more readable
Dorn	0.343	0–1; higher is more readable
Mi	0.039	0–1; higher is more readable
LLOC	23	Logical lines; fewer is more readable
DeepSeek V4 Pro	18	0–20; mean of three runs
GPT-6.1 Sol	18	0–20; mean of three runs
BTTF	0.63	0–1; higher is more readable

Views

Source code

package org.apache.kafka.connect.storage; import org.apache.kafka.connect.runtime.RestartRequest; import org.apache.kafka.connect.runtime.SessionKey; import org.apache.kafka.connect.runtime.TargetState; import org.apache.kafka.connect.util.ConnectorTaskId; import java.util.Collection; import java.util.List; import java.util.Map; import java.util.concurrent.TimeUnit; import java.util.concurrent.TimeoutException; /** * An interface to store and retrieve (via {@link #snapshot()}) configuration information that is created during * runtime (i.e. not static configuration like the {@link org.apache.kafka.connect.runtime.WorkerConfig worker config}). * This configuration information includes connector configs, task configs, connector target states etc. */ public interface ConfigBackingStore { void start(); void stop(); /** * Get a snapshot of the current configuration state including all connector and task * configurations. * @return the cluster config state */ ClusterConfigState snapshot(); /** * Check if the store has configuration for a connector. * @param connector name of the connector * @return true if the backing store contains configuration for the connector */ boolean contains(String connector); /** * Update the configuration for a connector. * @param connector name of the connector * @param properties the connector configuration * @param targetState the desired target state for the connector; may be {@code null} if no target state change is desired. Note that the default * target state is {@link TargetState#STARTED} if no target state exists previously */ void putConnectorConfig(String connector, Map<String, String> properties, TargetState targetState); /** * Remove configuration for a connector * @param connector name of the connector */ void removeConnectorConfig(String connector); /** * Update the task configurations for a connector. * @param connector name of the connector * @param configs the new task configs for the connector */ void putTaskConfigs(String connector, List<Map<String, String>> configs); /** * Remove the task configs associated with a connector. * @param connector name of the connector */ void removeTaskConfigs(String connector); /** * Refresh the backing store. This forces the store to ensure that it has the latest * configs that have been written. * @param timeout max time to wait for the refresh to complete * @param unit unit of timeout * @throws TimeoutException if the timeout expires before the refresh has completed */ void refresh(long timeout, TimeUnit unit) throws TimeoutException; /** * Transition a connector to a new target state (e.g. paused). * @param connector name of the connector * @param state the state to transition to */ void putTargetState(String connector, TargetState state); /** * Store a new {@link SessionKey} that can be used to validate internal (i.e., non-user-triggered) inter-worker communication. * @param sessionKey the session key to store */ void putSessionKey(SessionKey sessionKey); /** * Request a restart of a connector and optionally its tasks. * @param restartRequest the restart request details */ void putRestartRequest(RestartRequest restartRequest); /** * Record the number of tasks for the connector after a successful round of zombie fencing. * @param connector name of the connector * @param taskCount number of tasks used by the connector */ void putTaskCountRecord(String connector, int taskCount); /** * Prepare to write to the backing config store. May be required by some implementations (such as those that only permit a single * writer at a time across a cluster of workers) before performing mutating operations like writing configurations, target states, etc. * The default implementation is a no-op; it is the responsibility of the implementing class to override this and document any expectations for * when it must be invoked. */ default void claimWritePrivileges() { } /** * Emit a new level for the specified logging namespace (and all of its children). This level should * be applied by all workers currently in the cluster, but not to workers that join after it is stored. * @param namespace the namespace to adjust; may not be null * @param level the new level for the namespace; may not be null */ void putLoggerLevel(String namespace, String level); /** * Set an update listener to get notifications when there are new records written to the backing store. * @param listener non-null listener */ void setUpdateListener(UpdateListener listener); interface UpdateListener { /** * Invoked when a connector configuration has been removed * @param connector name of the connector */ void onConnectorConfigRemove(String connector); /** * Invoked when a connector configuration has been updated. * @param connector name of the connector */ void onConnectorConfigUpdate(String connector); /** * Invoked when task configs are updated. * @param tasks all the tasks whose configs have been updated */ void onTaskConfigUpdate(Collection<ConnectorTaskId> tasks); /** * Invoked when the user has set a new target state (e.g. paused) * @param connector name of the connector */ void onConnectorTargetStateChange(String connector); /** * Invoked when the leader has distributed a new session key * @param sessionKey the {@link SessionKey session key} */ void onSessionKeyUpdate(SessionKey sessionKey); /** * Invoked when a connector and possibly its tasks have been requested to be restarted. * @param restartRequest the {@link RestartRequest restart request} */ void onRestartRequest(RestartRequest restartRequest); /** * Invoked when a dynamic log level adjustment has been read * @param namespace the namespace to adjust; never null * @param level the level to set the namespace to; never null */ void onLoggingLevelUpdate(String namespace, String level); } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature	Value	Contribution (log-odds)
Source linesThe number of non-empty source lines.	168	+67.2
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.	1935.261	−63.864
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.399	−6.598

Intercept 8.87 + feature contributions = 5.608 (log-odds).
Score = sigmoid(5.608) = 0.996.

Score	0.879

Feature contributions

Feature	Value	Contribution (log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.	169	−4.947
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.	148.994	−2.646
Indentation frequencyHow rapidly indentation changes from line to line.	85	+2.203
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	167.953	+1.938
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.	148.982	+1.599
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.021	+0.735
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.	1	+0.398

Intercept 0.07 + feature contributions = -0.65 (log-odds).
Score = sigmoid(-0.65) = 0.343.

Score	0.039

Score	23

Run 1

This is an excellent example of readable code. The interface is well-structured with clear separation of concerns, grouping related methods logically. The Javadoc comments are thorough and provide clear intent for each method and parameter. Nesting is minimal (only one inner interface), and the code maintains a flat, easily scannable structure. Action granularity is perfect - each method signature occupies a single line. The reading flow is natural, with related operations (config, restart, logging) organized coherently. The code is concise without being overly terse. Minor deductions: the long method signature for putConnectorConfig could be formatted more cleanly, and the claimWritePrivileges default method interrupts the method flow slightly. Overall, this represents near-ideal interface design for maintainability and clarity.

Run 2

The code is a well-structured Java interface with clear intent and excellent readability. It follows a logical organization: class-level Javadoc, lifecycle methods, then data operations, a default method, and a nested listener interface. Nesting is minimal, limited to the nested UpdateListener interface, which is appropriate. Each method has concise Javadoc explaining its purpose, parameters, and exceptions. Method signatures are clear and use descriptive names (e.g., putConnectorConfig, removeTaskConfigs). The code avoids unnecessary length while maintaining completeness. Each method declaration is on one line, and Javadoc annotations are properly formatted. The reading flow is natural, progressing from general lifecycle to specific operations and ending with the callback interface. Minor deductions: some parameter descriptions could be more specific (e.g., in putLoggerLevel), and the default method claimWritePrivileges adds slight inconsistency. Overall, this is exemplary API design with high clarity and maintainability.

Run 3

This interface is highly readable due to its clear structure and comprehensive documentation. The code is organized logically with methods grouped by functionality (lifecycle, configuration, target state, session management). Nesting is minimal, limited to the single nested UpdateListener interface. Each method has a clear purpose, enhanced by detailed Javadoc comments explaining parameters and behavior. The code is concise without being overly brief — method signatures are one line each and avoid unnecessary verbosity. Action granularity is excellent, with each method performing a single conceptual operation. The reading flow is natural, progressing from lifecycle methods through configuration management to specialized operations. Minor deductions: some Javadoc lines are quite long, and the interface could benefit from grouping related methods with section comments, but overall this code exemplifies clean, maintainable API design.

Run 1

Code Structure: A well-organized interface separates storage operations from notifications through a nested UpdateListener interface. Nesting: Minimal, with only one nested interface and no complex control flow. Clarity of intent: Descriptive method names, explicit parameter types, and thorough Javadocs make responsibilities clear; start() and stop() lack documentation, and some domain terminology assumes Kafka knowledge. Code length: Declarations are concise, though repetitive documentation and several long comment lines increase visual length. Action granularity: Each declaration represents a single operation, with no compounded statements. Reading flow: Consistent spacing and documentation support natural scanning, although lifecycle, configuration, coordination, and logging methods could be grouped more explicitly.

Run 2

Code Structure: The interface logically groups configuration storage operations and isolates notification callbacks in UpdateListener. Nesting: Minimal, with only one nested interface and an empty default method. Clarity of intent: Descriptive method names, explicit types, and detailed Javadoc make responsibilities and parameters clear; start and stop lack documentation. Code length: Declarations are concise, though repetitive documentation and several long comment lines increase scanning effort. Action granularity: Each method declares a single operation, with no compound statements. Reading flow: Consistent spacing and documentation support natural top-to-bottom reading, although lifecycle, configuration, coordination, and logging methods could be grouped more explicitly. Overall, highly readable with minor documentation and organization improvements possible.

Run 3

1. Code Structure: Well-organized interface with related configuration operations and a clearly separated update-listener interface. 2. Nesting: Minimal nesting, limited to the listener interface and an empty default method. 3. Clarity of intent: Descriptive method names, typed parameters, and detailed Javadoc make responsibilities clear; lifecycle methods lack documentation. 4. Code length: Declarations are concise, though repetitive documentation and several long comment lines add visual bulk. 5. Action granularity: Each declaration expresses a single operation, with no compressed multi-action lines. 6. Reading flow: Consistent formatting and related operation pairs support natural scanning, although explicit grouping of lifecycle, configuration, coordination, and logging methods would improve navigation.