Sample
int-6454b1862717-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.998 | 0–1; higher is more readable |
| Scalabrino | 0.886 | 0–1; higher is more readable |
| Dorn | 0.698 | 0–1; higher is more readable |
| Mi | 0.293 | 0–1; higher is more readable |
| LLOC | 9 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.631 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 64 | +25.6 |
| 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 |
| 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.466 | −6.699 |
Intercept 8.87 + feature contributions = 6.204 (log-odds).
Score = sigmoid(6.204) = 0.998.
| Score | 0.886 |
|---|
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. | 122 | −1.502 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 121.985 | +1.164 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 54 | −0.876 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.032 | +0.627 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 63.78 | +0.482 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 35 | +0.473 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.836 (log-odds).
Score = sigmoid(0.836) = 0.698.
| Score | 0.293 |
|---|
| Score | 9 |
|---|
Run 1
This interface is highly readable. It follows a logical structure, grouping related methods (restore/completion, state transitions, status checks) cleanly. There is no nesting; the code is entirely flat. Each method's intent is clearly expressed through descriptive names and Javadoc comments, including nuanced behavior like standby changelogs never being fully read. The code is concise—no method implementations clutter the interface, and comments are informative without being verbose. Action granularity is excellent: each method declaration occupies one line within a clear signature. Reading flow is natural, starting with the primary restoration method, then mode transitions, status queries, and cleanup. The only minor deduction is the slight redundancy in some Javadoc, but it does not hinder readability. Overall, this is an exemplary public API interface in terms of clarity and maintainability.
Run 2
The code is highly readable due to its clear structure as a well-documented interface. Each method is concise, with a single clear action per declaration, and logical grouping of related functionality. Minimal nesting is present (only the package/import/interface structure), and the reading flow is natural, moving from restoration to state queries to cleanup. Javadoc comments effectively clarify intent, especially for methods with non-obvious behavior like allChangelogsCompleted(). Minor deduction only for slightly verbose documentation on some methods, but overall this is exemplary readability.
Run 3
The code is highly readable due to its clear structure as a well-documented interface. Each method has a Javadoc comment explaining its purpose, contributing to strong clarity of intent. The organization is logical, following a natural grouping of lifecycle methods and queries. Nesting is nonexistent, and the code is concise—no method body introduces unnecessary complexity. Reading flow is natural, with method names like 'enforceRestoreActive' and 'isRestoringActive' conveying action and state. Minor deductions: the interface references types like Task and ChangelogRegister without showing their definitions, but this is typical for an interface. Overall, it is an exemplary model of clean, maintainable code.
Run 1
Code Structure: The interface is logically organized, grouping restoration controls, status queries, and lifecycle operations. Nesting: Completely flat, with no nested control flow. Clarity of intent: Descriptive method names, explicit types, and Javadocs make the contract clear, though 'Transit' is awkward wording and logical end-offset semantics could be explained better. Code length: Concise declarations with mostly useful documentation; the completion-method comment is somewhat repetitive. Action granularity: Each declaration occupies its own line and represents a single operation or query. Reading flow: Consistent spacing and documentation support natural scanning, although separating the package declaration and import groups would improve formatting.
Run 2
Code Structure: A focused interface logically groups restoration, mode switching, completion queries, and cleanup. Nesting: No nested control flow; declarations are flat and easy to scan. Clarity of intent: Descriptive method names, explicit types, and Javadoc make responsibilities clear, though 'Transit' wording is awkward and the meaning of logical end-offsets could be explained better. Code length: Concise declarations with proportionate documentation; the completion-method comment is longer but explains an important standby-task caveat. Action granularity: Each method declaration occupies its own line and represents a distinct operation. Reading flow: Consistent formatting and documentation support natural reading, although separating the package and import sections with blank lines and grouping imports consistently would improve presentation.
Run 3
Code Structure: A well-organized interface groups related changelog restoration, mode switching, status queries, and cleanup operations. Nesting: Flat declarations with no nested control flow make scanning effortless. Clarity of intent: Descriptive method names, precise return types, and Javadocs clearly communicate most contracts; wording such as 'Transit' and 'logical changelog partitions end-offsets' is slightly awkward. Code length: Concise signatures avoid unnecessary implementation detail, though some documentation repeats method names. Action granularity: Each declaration expresses one operation, with no crowded statements. Reading flow: Methods progress naturally from restoration to mode management, completion queries, and cleanup. Missing whitespace between the package declaration and imports, and between import groups, slightly reduces visual polish.