Sample
int-244bd4834816-I13
Lower every eligible classic and enhanced for loop to a while loop
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 has a clear, logical structure as an interface defining graph connection operations. Nesting is minimal, with only concise Javadoc paragraphs. Intent for each method is clear from naming and documentation. Code length is appropriately concise for an interface. Each method declaration is one action per line, following consistent formatting. Reading flow is natural, progressing from simple accessors to more complex edge manipulation methods. Minor improvements could include grouping related methods (e.g., in/out pairs) with blank lines, but overall this is exemplary readable code.
Run 3
The code is highly readable. It has a clear, logical structure as an interface with well-separated method declarations. Nesting is minimal to nonexistent. The intent of each method is made clear through descriptive names and concise Javadoc comments. Code length is appropriate for the functionality, with no unnecessary repetition. Each action is granular and focused, following the single responsibility principle at the method level. The reading flow is natural: generic type parameters and imports come first, followed by a summary of node-edge relationships (adjacent, predecessor/successor, incident) and then specific edge operations. While the interface itself is clean, a minor deduction is made because some methods like `removeInEdge` and `addInEdge` involve boolean flags (`isSelfLoop`) that could slightly reduce clarity without deeper context, though the Javadoc mitigates this.
Run 1
Code Structure: The interface logically groups node queries, edge queries, and mutation operations. Nesting: No nested control flow; declarations remain flat. Clarity of intent: Descriptive method names, generic type documentation, and focused Javadocs make the purpose clear, including directed-edge and self-loop behavior. Code length: Concise, with useful comments rather than redundant explanation. Action granularity: Each method declaration represents one operation, with annotations clearly separated where appropriate. Reading flow: The progression from queries to removals and additions is natural, supported by consistent spacing. Minor limitations include undocumented semantics for basic query methods and the isSelfLoop parameter on addInEdge.
Run 2
Code Structure: The interface logically groups node queries, edge queries, removals, and additions. Nesting: The structure is flat, with no nested control flow. Clarity of intent: Descriptive method names, generic types, annotations, and targeted documentation clearly express responsibilities and return behavior; the meaning of isSelfLoop in addInEdge could be documented more explicitly. Code length: Declarations and comments are concise, with little redundancy. Action granularity: Each declaration occupies its own line and represents a single operation. Reading flow: Consistent formatting and progression from queries to mutations make the interface easy to scan, though separating the package declaration from imports with a blank line would improve presentation.
Run 3
Code Structure: The interface logically groups node queries, edge queries, removals, and additions. Nesting: Declarations are flat, with no nested control flow. Clarity of intent: Descriptive method names, generic type documentation, and focused comments make the purpose clear; annotations communicate nullability and return-value expectations. Some query methods lack documentation, and addInEdge does not explain isSelfLoop. Code length: Concise declarations and relevant comments avoid unnecessary verbosity. Action granularity: Each method declaration occupies its own line and expresses a distinct operation. Reading flow: Consistent formatting and progression from queries to mutations make scanning natural, though spacing between the package and imports would improve presentation.