Sample
int-71794f980557-I10
Remove about 40% of line-break groups while retaining structure
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.725 | 0–1; higher is more readable |
| Scalabrino | 0.835 | 0–1; higher is more readable |
| Dorn | 0.651 | 0–1; higher is more readable |
| Mi | 0.217 | 0–1; higher is more readable |
| LLOC | 9 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.618 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
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. | 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.
| Score | 0.835 |
|---|
Feature contributions
| Feature | Value | Contribution (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.
| Score | 0.217 |
|---|
| Score | 9 |
|---|
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.