Sample
int-cf04cbdb255f-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.135 | 0–1; higher is more readable |
| Scalabrino | 0.57 | 0–1; higher is more readable |
| Dorn | 0.769 | 0–1; higher is more readable |
| Mi | 0.727 | 0–1; higher is more readable |
| LLOC | 12 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 840.254 | −27.728 |
| Source linesThe number of non-empty source lines. | 60 | +24 |
| 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.665 | −6.998 |
Intercept 8.87 + feature contributions = -1.856 (log-odds).
Score = sigmoid(-1.856) = 0.135.
| Score | 0.57 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 58 | −1.017 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.721 | +0.756 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 40 | +0.646 |
| 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. | 99.984 | −0.57 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.488 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 59.941 | +0.428 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 1.2 (log-odds).
Score = sigmoid(1.2) = 0.769.
| Score | 0.727 |
|---|
| Score | 12 |
|---|
Run 1
This interface is highly readable and well-structured. The code organization is logical, with method declarations grouped into sections (adjacent nodes, incident edges, edge operations) and separated by whitespace. Nesting is minimal - only the class/interface declaration and method bodies are nested, making the code flat and easy to scan. Intent is crystal clear through descriptive method names and purposeful Javadoc comments that explain each method's behavior and edge cases. The code length is concise - no unnecessary boilerplate or redundant annotations. Action granularity is appropriate for an interface, with each method declaration on its own line. Reading flow is natural, moving from basic accessor methods to more complex edge operations in a progressive manner. The only minor deduction is for the slightly verbose Javadoc on some methods, but this actually enhances understanding rather than hindering readability. Overall, this is exceptionally clean, well-documented Java code.
Run 2
The code is highly readable. It is a clean interface definition with a logical grouping of related methods (adjacency, edges, modifications). Nesting is effectively flat. Intent is clearly expressed through descriptive method names and concise Javadoc comments. The code is concise without being overly dense. Most methods are single-action declarations. Reading flow is natural, progressing from general queries to specific modifications. The only minor deductions are for a few method names that could be slightly more explicit and the inherent brevity of interface declarations.
Run 3
The code is highly readable, with clear logical organization as a well-defined interface. It uses flat nesting with no conditional or loop structures. Each method has a clear purpose, supported by concise Javadoc comments. The methods are short and focused, maintaining single-action granularity. The reading flow is natural and intuitive, grouping related methods (adjacent nodes, edges, in/out operations) in a logical order. Minor deductions are due to the slightly verbose Javadoc for straightforward methods, but overall clarity remains excellent.
Run 1
Code Structure: The interface logically groups node queries, edge queries, and mutation methods. Nesting: There is no nested control flow, making the declarations easy to scan. Clarity of intent: Descriptive method names, generic types, annotations, and focused Javadoc clearly communicate purpose and important directed/undirected behavior. Minor gaps include undocumented basic queries and limited explanation of isSelfLoop in addInEdge. Code length: The interface is concise, with documentation adding useful context rather than unnecessary bulk. Action granularity: Each declaration describes a single operation; annotations are clearly associated with their methods. Reading flow: Consistent formatting and progression from inspection to mutation support natural reading, although explicit grouping comments could improve navigation slightly.
Run 2
Code Structure: Methods are logically grouped into node queries, edge queries, removals, and additions. Nesting: The interface is flat, with no nested control flow. Clarity of intent: Descriptive method names, generic type documentation, and focused Javadocs make the contract clear; directed-edge assumptions and nullable results are explicitly documented. Code length: Declarations and comments are concise without unnecessary repetition. Action granularity: Each method declaration occupies its own line and represents a focused operation. Reading flow: Consistent spacing and ordering support easy scanning from queries to mutations. Minor shortcomings include missing documentation for the initial query methods and limited explanation of the isSelfLoop parameter on addInEdge.
Run 3
Code Structure: The interface logically groups node queries, edge queries, removals, and additions. Nesting: It is flat, with no nested control flow. Clarity of intent: Descriptive method names, generic types, annotations, and targeted Javadoc make the contract clear; however, several query methods lack documentation, and the addInEdge self-loop parameter is not explained. Code length: The interface is concise, with useful rather than excessive comments. Action granularity: Each declaration expresses a single operation, with no bundled statements. Reading flow: Consistent formatting and progression from inspection to mutation support natural reading, though a blank line after the package declaration would improve separation.