Sample
int-9c357eb7e9cf-I07
Insert deterministic runtime-dead branches into callable bodies
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.67 | 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 interface is highly readable, with clear method names and Javadoc comments explaining intent. Structure is logical and flat, with no nested code. Each method is concise and performs a single logical action. The import statements and package declaration follow standard conventions. Minor deductions for slightly verbose comments and lack of blank lines between methods, but overall the code is well-organized and easy to understand.
Run 3
The code is an interface with a clear, single-purpose contract. Each method is documented with Javadoc comments that explain intent, parameters, and return values. The structure is logical and straightforward—no complex nesting, no ambiguous names, and no redundant code. The reading flow is natural, with related methods grouped and comments enhancing understanding. The code is concise, with each method doing exactly what its name suggests. Only minor improvement could be adding a brief class-level explanation of the relationship between methods, but overall it is highly readable.
Run 1
Code Structure: The interface is logically organized, grouping restoration controls, status queries, and cleanup methods. Nesting: Flat declarations with no nested control flow make scanning easy. Clarity of intent: Descriptive method names, explicit return types, and Javadoc communicate responsibilities well; awkward wording such as “Transit to” and the unexplained “logical” end-offsets slightly reduce precision. Code length: Concise for the exposed API, though the allChangelogsCompleted documentation repeats its condition. Action granularity: Each method declaration occupies its own line and represents a distinct operation. Reading flow: Consistent spacing and documentation support a natural top-to-bottom reading order, although separating the package declaration and import groups with blank lines would improve presentation.
Run 2
Code Structure: A well-organized interface groups related changelog restoration operations, queries, and lifecycle methods. Nesting: No nested logic; all declarations are flat. Clarity of intent: Descriptive method names, explicit types, and Javadoc make responsibilities clear, though wording such as 'Transit' and 'logical changelog partitions end-offsets' could be improved. Code length: Concise declarations with proportionate documentation; the longer completion comment explains an important standby-task caveat. Action granularity: Each declaration occupies its own line and represents a single operation or query. Reading flow: Consistent spacing and documentation support natural scanning from restoration controls to status checks and cleanup. Minor drawbacks include the lack of separation between package and imports and inconsistent naming between enforceRestoreActive and transitToUpdateStandby.
Run 3
Code Structure: A well-organized interface groups restoration, mode transitions, progress queries, and lifecycle operations logically. Nesting: Flat method declarations impose no nesting burden. Clarity of intent: Descriptive names, explicit types, and Javadoc communicate responsibilities clearly, though phrases such as 'Transit to' and 'logical changelog partitions end-offsets' could be more precise. Code length: Concise declarations with proportionate documentation; the longer completion comment usefully explains standby behavior. Action granularity: Each declaration represents one operation, with no compound statements. Reading flow: Consistent formatting and documentation support natural scanning, although separating package and import sections with blank lines would improve presentation.