Sample

int-71794f980557-I10

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

Matched original source

Lines51

Scores

MethodScoreScale
Posnett0.7250–1; higher is more readable
Scalabrino0.8350–1; higher is more readable
Dorn0.6510–1; higher is more readable
Mi0.2170–1; higher is more readable
LLOC9Logical lines; fewer is more readable
DeepSeek V4 Pro9.330–20; mean of three runs
GPT-6.1 Sol140–20; mean of three runs
BTTF0.6180–1; higher is more readable

Views

Source code

package org.apache.kafka.streams.processor.internals; import org.apache.kafka.common.TopicPartition; import org.apache.kafka.streams.processor.TaskId; import java.util.Map; import java.util.Set; /** * See {@link StoreChangelogReader}. */ public interface ChangelogReader extends ChangelogRegister { /** * Restore all registered state stores by reading from their changelogs * * @return the total number of records restored in this call */ long restore(final Map<TaskId, Task> tasks); /** * Transit to restore active changelogs mode */ void enforceRestoreActive(); /** * Transit to update standby changelogs mode */ void transitToUpdateStandby(); /** * @return true if the reader is in restoring active changelog mode; * false if the reader is in updating standby changelog mode */ boolean isRestoringActive(); /** * @return the changelog partitions that have been completed restoring */ Set<TopicPartition> completedChangelogs(); /** * @return the logical changelog partitions end-offsets */ Map<TopicPartition, Long> logicalChangelogEndOffsets(); /** * Returns whether all changelog partitions were completely read. * * Since changelog partitions for standby tasks are never completely read, this method will always return * {@code false} if the changelog reader registered changelog partitions for standby tasks. * * @return {@code true} if all changelog partitions were completely read and no standby changelog partitions are read, * {@code false} otherwise */ boolean allChangelogsCompleted(); /** * Clear all partitions */ void clear(); /** * @return whether the changelog reader has just been cleared or is uninitialized */ boolean isEmpty(); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.653.531−21.567
Source linesThe number of non-empty source lines.51+20.4
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.488−6.732

Intercept 8.87 + feature contributions = 0.972 (log-odds).
Score = sigmoid(0.972) = 0.725.

Score0.835

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.121.981−1.501
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.121.981+1.164
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.033+0.623
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.42−0.451
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.50.65+0.298
Indentation frequencyHow rapidly indentation changes from line to line.22+0.024

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

Score0.217
Score9
Run 1

The code structure is logical as an interface definition, but readability is significantly compromised by formatting issues. Multiple method declarations and their Javadoc comments are placed on the same line, breaking the natural vertical reading flow and making the interface appear tangled. Nesting is not an issue, but clarity of intent suffers because the compressed layout obscures method boundaries. Code length is appropriate for the domain, but action granularity is poor—several declarations are crammed onto single lines instead of one per line. Reading flow is disjointed due to inconsistent spacing and Javadoc placement. While the method names and comments themselves are descriptive, the physical layout undermines comprehension. Proper line breaks between methods and consistent formatting would improve readability substantially.

Run 2

The code defines a clear interface with mostly good Javadoc comments, but readability suffers from severe formatting issues. Import statements are combined on single lines, and multiple methods are crammed onto the same line, particularly the methods isRestoringActive(), completedChangelogs(), and logicalChangelogEndOffsets(). This violates the 'one action per line' principle and disrupts natural reading flow. The code length is concise but at the cost of clarity. The structure and intent are logical, but the poor formatting makes the code appear tangled and harder to scan. Nesting is not an issue since it is an interface. Overall, the content is understandable, but the presentation significantly reduces readability.

Run 3

The interface method declarations are mostly clear, but the code suffers from severe structural issues. Multiple method declarations and Javadocs are crammed onto single lines, with imports also bunched together. This violates action granularity and natural reading flow, forcing the reader to parse dense clusters of code. Nesting is minimal, but clarity of intent is undermined by broken Javadoc alignment and inline declarations. While the code is not excessively long, it is unnecessarily compressed in places, making it feel tangled and disorganized. Overall, the poor formatting significantly reduces readability despite the otherwise straightforward content.

Run 1

Code Structure: The interface logically groups related changelog operations, but inconsistent formatting weakens organization. Nesting: There is no deep nesting; method declarations are flat and easy to scan. Clarity of intent: Descriptive names, types, and Javadoc communicate purpose well, although phrases such as 'Transit to' are awkward. Code length: The interface is concise, with documentation providing useful behavioral context. Action granularity: Two imports share a line, and several method declarations share lines with comment boundaries, reducing visual separation. Reading flow: The operation sequence is coherent, but comments attached to preceding declarations and the closing brace placed beside the final method interrupt scanning. Consistent line breaks and spacing would substantially improve readability.

Run 2

Code Structure: The interface logically groups changelog restoration, status queries, and cleanup operations, but inconsistent formatting obscures method boundaries. Nesting: Flat declarations with no nested control flow make scanning straightforward. Clarity of intent: Descriptive method names, explicit types, and Javadoc convey responsibilities well, although wording such as 'Transit' is awkward. Code length: Concise and appropriate for an interface; documentation adds useful context rather than unnecessary complexity. Action granularity: Multiple imports share a line, and several declarations share lines with comment delimiters or the closing brace, reducing visual separation. Reading flow: The conceptual order is natural, but cramped transitions between documentation and declarations interrupt reading. Consistent line breaks and spacing would substantially improve readability.

Run 3

Code Structure: The interface groups related changelog operations logically, but inconsistent formatting weakens visual organization. Nesting: Very shallow, with no nested control flow. Clarity of intent: Descriptive method names, explicit types, and Javadoc make the API's purpose clear, though some comments use awkward wording. Code length: Concise and appropriate for an interface; documentation adds useful context. Action granularity: Several imports, declarations, comment boundaries, and the closing brace share lines, reducing separation between distinct elements. Reading flow: The method sequence is understandable, but declarations attached to Javadoc endings and comments starting immediately after declarations interrupt scanning. Consistent line breaks and spacing would substantially improve readability.