Sample

int-0b657c58148d-I10

Remove about 40% of line-break groups while retaining structure

DatasetJava transformations

Lines135

Scores

Method	Score	Scale
Posnett	0	0–1; higher is more readable
Scalabrino	0.864	0–1; higher is more readable
Dorn	0.266	0–1; higher is more readable
Mi	0.015	0–1; higher is more readable
LLOC	23	Logical lines; fewer is more readable
DeepSeek V4 Pro	5.67	0–20; mean of three runs
GPT-6.1 Sol	14	0–20; mean of three runs
BTTF	0.622	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)
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
Source linesThe number of non-empty source lines.	135	+54
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.418	−6.627

Intercept 8.87 + feature contributions = -7.621 (log-odds).
Score = sigmoid(-7.621) = 0.

Score	0.864

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.	134	−3.708
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.	149	−2.646
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.	148.971	+1.599
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	134.927	+1.476
Indentation frequencyHow rapidly indentation changes from line to line.	52	+1.061
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.022	+0.732
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.	1	+0.398

Intercept 0.07 + feature contributions = -1.017 (log-odds).
Score = sigmoid(-1.017) = 0.266.

Score	0.015

Score	23

Run 1

This code is poorly readable due to severe formatting issues. Multiple method declarations and their Javadoc blocks are crammed onto single lines (e.g., interface declaration, removeConnectorConfig, putTaskConfigs, removeTaskConfigs, refresh, putSessionKey, putTaskCountRecord, claimWritePrivileges, putLoggerLevel, setUpdateListener, onSessionKeyUpdate, onRestartRequest, onLoggingLevelUpdate). This destroys visual separation between methods and makes scanning difficult. Nesting is minimal, which is good, and the logic itself is straightforward interface definition, but the collapsed formatting obscures it. Code length is inflated because compressed lines still contain full documentation, creating massive horizontal lines. Action granularity is violated—multiple actions (method docs, annotations, declarations) share single lines. The natural reading flow is completely broken. While the interface itself has clear intent, the formatting makes extraction of that intent extremely difficult. Spacing and line breaks would immediately improve readability.

Run 2

The code is a Java interface with severe formatting issues that hurt readability. Imports are crammed onto single lines, and method closing braces are placed immediately before the next Javadoc comment, making it difficult to distinguish where one method ends and the next begins. Some Javadoc blocks are also placed on the same line as the method signature, rather than above it. While the method names and parameter types are descriptive, the overall structure appears tangled due to inconsistent spacing and indentation. The 'Action granularity' is poor because multiple declarations and statements share lines. Reading flow is disorganized, forcing the reader to parse carefully to separate members. If properly formatted with standard Java conventions, this interface would be quite readable, but as presented it falls well below acceptable readability standards.

Run 3

The code is severely impacted by formatting issues that make it difficult to read. Multiple imports are on the same line, and numerous method declarations and Javadoc comments start on the same line as preceding code, disrupting visual structure. While the interface itself has a logical organization of related methods, the lack of proper line breaks obscures this structure. Nesting is minimal, clarity of intent is reduced due to cramped comments and declarations, and reading flow is consistently interrupted. Code length is appropriate for the functionality, but action granularity is poor because multiple actions (imports, method declarations) occupy single lines. Overall, the content is understandable but the presentation significantly degrades readability.

Run 1

Code Structure: Related storage operations are grouped in one interface, with update callbacks logically separated into a nested interface. Nesting: Very shallow, with no complex control flow. Clarity of intent: Descriptive method names, explicit types, and detailed Javadocs clearly communicate responsibilities. Code length: Appropriate for the API's scope, though documentation dominates and some lines are excessively long. Action granularity: Multiple imports and method declarations share lines, while declarations frequently follow closing comment delimiters on the same line, reducing scanability. Reading flow: The operation order is generally natural, but inconsistent spacing, compressed declarations, and comments beginning immediately after methods interrupt visual flow. Overall, the API is understandable, but poor formatting noticeably weakens readability.

Run 2

Code Structure: The interface logically groups configuration-storage operations and places notification callbacks in a separate nested interface. Nesting: Minimal nesting and no complex control flow make it easy to follow. Clarity of intent: Descriptive method names, explicit types, and detailed Javadoc clearly communicate responsibilities and parameter meanings. Code length: Method declarations are concise; documentation adds useful context, although some lines are excessively long. Action granularity: Several imports and method declarations share lines, while comment boundaries frequently share lines with declarations or closing braces, weakening visual separation. Reading flow: The overall sequence is understandable, but inconsistent spacing, compressed declarations, and irregular comment placement interrupt scanning. Consistent formatting and one declaration per line would substantially improve readability.

Run 3

Code Structure: The interface logically groups configuration operations and nests related callbacks in UpdateListener, though formatting weakens visual separation. Nesting: Minimal nesting and no complex control flow make the code easy to follow. Clarity of intent: Descriptive method names, explicit parameter types, and informative Javadocs clearly communicate responsibilities. Code length: Declarations are concise; documentation adds useful context, although some lines are excessively long. Action granularity: Several imports and method declarations share lines, while comment boundaries frequently share lines with declarations, reducing scanability. Reading flow: The overall API order is understandable, but inconsistent spacing, compressed declarations, and attached comments interrupt natural reading. Strong naming and documentation preserve readability despite substantial formatting issues.