Sample

int-56a2f9083de6-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines168

Scores

MethodScoreScale
Posnett0.9760–1; higher is more readable
Scalabrino0.9010–1; higher is more readable
Dorn0.070–1; higher is more readable
Mi0.0410–1; higher is more readable
LLOC23Logical lines; fewer is more readable
DeepSeek V4 Pro3.330–20; mean of three runs
GPT-6.1 Sol11.330–20; mean of three runs
BTTF0.5640–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 sta(); void sto(); /** * Get a snapshot of the current configuration state including all connector and task * configurations. * @return the cluster config state */ ClusterConfigState sna(); /** * 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 con(String con); /** * 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 put(String con2, Map<String, String> pro, TargetState target); /** * Remove configuration for a connector * @param connector name of the connector */ void remove(String con3); /** * Update the task configurations for a connector. * @param connector name of the connector * @param configs the new task configs for the connector */ void put2(String con4, List<Map<String, String>> con5); /** * Remove the task configs associated with a connector. * @param connector name of the connector */ void remove2(String con6); /** * 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 ref(long tim, TimeUnit uni) 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 put3(String con7, TargetState sta); /** * 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 put4(SessionKey session); /** * Request a restart of a connector and optionally its tasks. * @param restartRequest the restart request details */ void put5(RestartRequest restart); /** * 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 put6(String con8, int task); /** * 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 claim() { } /** * 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 put7(String nam, String lev); /** * Set an update listener to get notifications when there are new records written to the backing store. * @param listener non-null listener */ void set(UpdateListener lis); interface UpdateListener { /** * Invoked when a connector configuration has been removed * @param connector name of the connector */ void on(String con9); /** * Invoked when a connector configuration has been updated. * @param connector name of the connector */ void on2(String con10); /** * Invoked when task configs are updated. * @param tasks all the tasks whose configs have been updated */ void on3(Collection<ConnectorTaskId> tas); /** * Invoked when the user has set a new target state (e.g. paused) * @param connector name of the connector */ void on4(String con11); /** * Invoked when the leader has distributed a new session key * @param sessionKey the {@link SessionKey session key} */ void on5(SessionKey session2); /** * Invoked when a connector and possibly its tasks have been requested to be restarted. * @param restartRequest the {@link RestartRequest restart request} */ void on6(RestartRequest restart2); /** * 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 on7(String nam2, String lev2); } }

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.1992.999−65.769
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.392−6.588

Intercept 8.87 + feature contributions = 3.713 (log-odds).
Score = sigmoid(3.713) = 0.976.

Score0.901

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.988−2.645
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
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.85−1.53
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.023+0.721

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

Score0.041
Score23
Run 1

This code is severely obfuscated and unreadable. Method names have been reduced to meaningless tokens like 'sta()', 'sto()', 'sna()', 'con()', and 'put2()' through 'put7()', destroying the original descriptive names (start, stop, snapshot, contains, putConnectorConfig, putTaskConfigs, etc.). Parameter names like 'con2', 'pro', 'con5', 'tim', 'uni', 'sta', 'nam', 'lev', 'lis', and 'session2' provide no semantic meaning. While the Javadoc comments remain descriptive, they create a jarring disconnect with the degraded code they document. The interface structure is logically organized, and each method performs a single action, but the cryptic naming completely obscures the intent and makes the code extremely difficult to follow without constantly cross-referencing comments. This represents a worst-case scenario where otherwise well-structured code is rendered nearly unreadable through deliberate name mangling.

Run 2

The code is structurally intact (proper package, imports, interface) but unreadable due to intentional obfuscation of all identifiers. Method names like 'sta', 'sto', 'sna', 'con', 'put2', 'put7' obscure intent completely. Parameter names are cryptic ('con7', 'nam2', 'session2'). This violates clarity of intent, reading flow, and action granularity. While the Javadoc comments are detailed, they do not map meaningfully to the mangled method names, causing cognitive friction. Nesting is flat, but method count and arbitrary numbering create disorganization. Code is concise, but at the cost of meaning. Overall, the structure shows an underlying API, but the deliberate removal of meaningful names makes it effectively unreadable for practical use.

Run 3

The code is severely obfuscated through systematic renaming of all methods and parameters to meaningless abbreviations (sta, sto, sna, con, con2, con3, etc.). This destroys clarity of intent completely, making the interface impossible to understand without external documentation. While the structure retains some logical grouping and nesting is flat, the code length is artificially reduced at the expense of all semantic meaning. Action granularity is technically one action per line, but reading flow is completely disrupted by the nonsensical names. The Javadoc comments still describe original intent, creating a jarring disconnect between documentation and code. This appears to be deliberately de-identified code that would fail any professional code review.

Run 1

Code Structure: Logically organized as a storage interface with a separate nested listener interface. Nesting: Shallow, with no complex control flow. Clarity of intent: Substantially weakened by abbreviated names and numbered methods such as put2, put7, and on6; descriptive Javadocs help, but mismatched @param names and the nonexistent snapshot() reference undermine accuracy. Code length: Reasonable for the API scope, although documentation dominates and some lines are overly long. Action granularity: Each declaration occupies its own line, making individual operations easy to isolate. Reading flow: Consistent spacing and method documentation support scanning, but understanding operations requires repeatedly consulting comments because signatures convey little meaning.

Run 2

Code Structure: The interface logically groups storage operations and separates callbacks into UpdateListener. Nesting: Minimal nesting makes declarations easy to scan. Clarity of intent: Severely weakened by abbreviated names such as sta, sna, and con, and numbered methods such as put2 and on6. Documentation explains most operations, but parameter tags do not match actual names, and the snapshot link references a nonexistent method. Code length: Declarations are concise; extensive documentation is mostly useful but compensates for poor naming. Action granularity: Each declaration occupies its own line, with no combined actions. Reading flow: Consistent spacing and method-level comments support navigation, but opaque identifiers force readers to consult documentation repeatedly. Overall, strong structural readability is undermined by ambiguous naming and inconsistent documentation.

Run 3

Code Structure: The interface is logically organized, with storage operations followed by a nested update-listener interface. Nesting: Minimal nesting and no complex control flow make the layout easy to scan. Clarity of intent: Severely weakened by abbreviated and numbered names such as sta, put6, and on7; readers must rely on documentation to distinguish operations. Javadoc parameter names do not match declarations, and the snapshot link references a missing method, reducing documentation reliability. Code length: Declarations are concise, although extensive comments compensate for unclear naming and include some long lines. Action granularity: Each declaration represents a single operation, with no combined statements. Reading flow: Consistent spacing and documentation support sequential reading, but cryptic identifiers and documentation mismatches repeatedly interrupt comprehension.