Sample

int-324b82504f9f-I03

Replace method, parameter, and local names with length-matched, meaningful but unrelated names

Matched original source

Lines168

Scores

MethodScoreScale
Posnett0.9870–1; higher is more readable
Scalabrino0.8950–1; higher is more readable
Dorn0.3420–1; higher is more readable
Mi0.0390–1; higher is more readable
LLOC23Logical lines; fewer is more readable
DeepSeek V4 Pro30–20; mean of three runs
GPT-6.1 Sol10.670–20; mean of three runs
BTTF0.580–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 check(); void read(); /** * Get a snapshot of the current configuration state including all connector and task * configurations. * @return the cluster config state */ ClusterConfigState evaluate(); /** * 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 findNode(String reference); /** * 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 validateBalance(String nextCount, Map<String, String> pendingKey, TargetState secureIndex); /** * Remove configuration for a connector * @param connector name of the connector */ void validateAddress(String nextValue); /** * Update the task configurations for a connector. * @param connector name of the connector * @param configs the new task configs for the connector */ void validateStatus(String nextOrder, List<Map<String, String>> channel); /** * Remove the task configs associated with a connector. * @param connector name of the connector */ void validateMessage(String recentKey); /** * 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 sendKey(long feature, TimeUnit path) 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 validateRecord(String finalMode, TargetState value); /** * 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 createBalance(SessionKey finalBatch); /** * Request a restart of a connector and optionally its tasks. * @param restartRequest the restart request details */ void validateAccount(RestartRequest primaryAddress); /** * 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 validateSession(String nextScore, int localUser); /** * 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 validateRequest() { } /** * 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 validateClient(String finalUser, String limit); /** * Set an update listener to get notifications when there are new records written to the backing store. * @param listener non-null listener */ void refreshAccount(UpdateListener customer); interface UpdateListener { /** * Invoked when a connector configuration has been removed * @param connector name of the connector */ void validateMessage(String nextToken); /** * Invoked when a connector configuration has been updated. * @param connector name of the connector */ void validateBalance(String localNode); /** * Invoked when task configs are updated. * @param tasks all the tasks whose configs have been updated */ void validateAddress(Collection<ConnectorTaskId> event); /** * Invoked when the user has set a new target state (e.g. paused) * @param connector name of the connector */ void validateSession(String nextEvent); /** * Invoked when the leader has distributed a new session key * @param sessionKey the {@link SessionKey session key} */ void validateRequest(SessionKey finalIndex); /** * Invoked when a connector and possibly its tasks have been requested to be restarted. * @param restartRequest the {@link RestartRequest restart request} */ void validateAccount(RestartRequest currentRequest); /** * 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 validateConfig(String nextBatch, String state); } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.1972.863−65.104
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.412−6.618

Intercept 8.87 + feature contributions = 4.347 (log-odds).
Score = sigmoid(4.347) = 0.987.

Score0.895

Feature contributions

FeatureValueContribution
(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.927+1.937
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.022+0.733
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.653 (log-odds).
Score = sigmoid(-0.653) = 0.342.

Score0.039
Score23
Run 1

This code is severely obfuscated. Method names like 'validateBalance', 'sendKey', 'validateAccount', and 'createBalance' bear no semantic relation to the interface's documented purpose (storing configuration). The parameter names are equally misleading ('nextCount', 'pendingKey', 'secureIndex'), making it impossible to infer intent despite extensive Javadoc. The interface appears to have been deliberately renamed, destroying clarity. Nesting is minimal, and the structure is logically organized at a high level, but the naming obliterates readability. The Javadoc comments contradict the methods, creating confusion rather than clarity. Action granularity is fine, but the reading flow is disorienting. This code fails to communicate its purpose effectively, making it nearly unreadable to any developer unfamiliar with the original method names and parameter semantics.

Run 2

The code appears to be an obfuscated or deliberately corrupted version of the Kafka Connect ConfigBackingStore interface. While the overall structure follows a standard Java interface pattern, the implementation is severely compromised. Method names (validateBalance, validateAddress, validateStatus, etc.) do not match their documented purposes or parameter types (e.g., 'findNode' takes 'reference' but documentation says 'connector'). Parameter names are misleading ('nextCount', 'pendingKey', 'secureIndex' for connector/targetState). Javadoc comments describe correct functionality but do not align with method signatures. This creates extreme confusion between intent and implementation. Reading flow is broken by inconsistent naming across methods and parameters. The code is practically unreadable and unmaintainable, despite having proper formatting and structure on the surface.

Run 3

The code has major readability issues. While it retains an interface structure, the method names and parameter names are nonsensical (e.g., 'validateBalance', 'sendKey', 'refreshAccount', 'localUser', 'pendingKey') and do not reflect the operations described in the Javadoc comments, making the purpose ambiguous. The Javadoc comments themselves describe standard configuration store operations, but the identifiers are completely disconnected from those descriptions, creating confusion. Nesting is minimal and the structure is flat, but clarity of intent is severely compromised. Method parameters are poorly named and do not communicate their meaning. The code is not overly long, but the naming makes it effectively unreadable. Despite having one action per method, the reading flow is disrupted by the mismatch between comments and actual code identifiers.

Run 1

Code Structure: Logically organized as a storage interface with a nested update-listener interface and consistent method separation. Nesting: Minimal, with only one nested interface and an empty default method. Clarity of intent: Severely weakened by misleading method and parameter names such as validateBalance and secureIndex. Documentation explains intended operations, but @param names do not match signatures, and the snapshot() reference does not match evaluate(). Undocumented check() and read() are ambiguous. Code length: Method declarations are concise; extensive documentation is mostly useful, though some lines are overly long. Action granularity: Each declaration occupies its own line, with no bundled operations. Reading flow: Consistent formatting supports scanning, but readers must repeatedly reconcile documentation with unrelated identifiers, disrupting comprehension.

Run 2

1. Code Structure: Logically organized as a storage interface with a nested update-listener interface and consistently separated declarations. 2. Nesting: Very shallow, with no complex control flow. 3. Clarity of intent: Severely weakened by misleading method and parameter names, such as validateBalance for updating configurations. Javadoc parameter names do not match signatures, the snapshot() reference points to an absent method, and check() and read() lack explanations. Documentation conveys intended behavior but conflicts with the API. 4. Code length: Appropriate for the interface's scope, although lengthy comments and long lines reduce scanability. 5. Action granularity: Each declaration occupies its own line; no bundled actions. 6. Reading flow: Consistent formatting and operation-by-operation documentation provide a natural progression, but readers must repeatedly reconcile descriptions with unrelated identifiers.

Run 3

Code Structure: The interface is logically organized, with store operations followed by a nested listener interface. Nesting: Minimal and easy to follow; there is no deeply nested control flow. Clarity of intent: Severely weakened by misleading method and parameter names, such as validateBalance for updating connector configuration. Documentation helps explain operations, but @param names do not match signatures, the snapshot() reference is missing, and check()/read() lack explanations. Code length: Reasonable for the API's scope, although lengthy comments compensate for poor naming. Action granularity: Each declaration occupies its own line, with no bundled actions. Reading flow: Consistent formatting and spacing make scanning straightforward, but repeated generic names and contradictions between signatures and documentation force readers to reinterpret each operation.