Sample
int-cb98e370cce6-I13
Lower every eligible classic and enhanced for loop to a while loop
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.998 | 0–1; higher is more readable |
| Scalabrino | 0.931 | 0–1; higher is more readable |
| Dorn | 0.706 | 0–1; higher is more readable |
| Mi | 0.335 | 0–1; higher is more readable |
| LLOC | 3 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.658 | 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. | 57 | +22.8 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 560.253 | −18.488 |
| 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.763 | −7.145 |
Intercept 8.87 + feature contributions = 6.037 (log-odds).
Score = sigmoid(6.037) = 0.998.
| Score | 0.931 |
|---|
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. | 57 | −0.982 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.621 | +0.754 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.029 | +0.656 |
| 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.948 | −0.568 |
| 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. | 56.881 | +0.385 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 26 | +0.162 |
Intercept 0.07 + feature contributions = 0.876 (log-odds).
Score = sigmoid(0.876) = 0.706.
| Score | 0.335 |
|---|
| Score | 3 |
|---|
Run 1
The code is highly readable. It has clear structure as an interface with well-organized Javadoc comments, a single logical purpose, and no complex nesting. Intent is unambiguous through descriptive method names and documentation. The code is concise, with each method declaration on its own line and no unnecessary verbosity. Action granularity is appropriate for an interface definition. Reading flow is natural: the peek() method is defined first as the primary addition, followed by overridden next() and remove() with clarifying documentation. Minor deductions come from the long Javadoc blocks which somewhat interrupt the code flow, and the generic type parameter '<E extends @Nullable Object>' adds slight complexity. Overall, the interface is clean, well-documented, and easy to understand.
Run 2
The code is highly readable with clear structure, flat organization, and minimal nesting. Each method (peek, next, remove) is concise with good Javadoc explaining intent and edge cases. Annotations are appropriately used and don't obscure readability. The interface is short, purposeful, and follows clean separation of concerns. Minor deductions include lengthy doc formatting that slightly lengthens the file and some inherited documentation could be terser, but overall flow, intent, and granularity are excellent.
Run 3
The code is exceptionally readable due to its clear structure and comprehensive documentation. It follows a logical organization—package declaration, imports, class-level Javadoc, then method definitions with detailed contracts. Nesting is flat: a single interface with three methods, each documented in detail. Intent is unambiguous; the `peek()` method's behavior, state effects, and exceptions are explicitly described. The code is concise for a formal API definition, avoiding unnecessary length. Each method signature and annotation is on its own line, adhering to one-action-per-line granularity. Reading flow is natural, mirroring typical Java API conventions and providing helpful examples and edge case explanations. Minor deductions are only for the density of Javadoc, which while valuable, slightly slows scanning, but overall clarity remains excellent.
Run 1
1. Code Structure: Logically organized interface with imports, class-level documentation, and clearly separated method contracts. 2. Nesting: Flat declarations with no nested control flow. 3. Clarity of intent: Descriptive names and precise documentation clearly explain lookahead behavior, return guarantees, and removal restrictions. 4. Code length: Concise interface; documentation is longer than the declarations but useful for defining subtle behavior. 5. Action granularity: Each method declaration and annotation occupies its own line, making individual elements easy to identify. 6. Reading flow: Natural progression from interface purpose to peek(), next(), and remove(). Minor readability friction comes from tightly packed package/import lines and awkwardly wrapped Javadoc links.
Run 2
Code Structure: A small, logically organized interface groups three closely related iterator operations. Nesting: No nested control flow; declarations are flat and easy to scan. Clarity of intent: Descriptive names and precise Javadoc explain lookahead behavior, state constraints, and exceptions. Code length: The interface is concise; documentation is longer than the declarations but provides useful contract details. Action granularity: Each method declaration and annotation occupies its own line, with no combined actions. Reading flow: The progression from peek() to next() to remove() naturally introduces lookahead and its effects on standard iterator operations. Minor readability drawbacks include dense annotation syntax, awkward wrapping of some Javadoc links, and the lack of blank lines separating the package and imports.
Run 3
Code Structure: The interface is logically organized, with imports, interface documentation, and three clearly separated method declarations. Nesting: There is no nested control flow; only a single interface scope. Clarity of intent: Descriptive names and precise Javadocs clearly explain lookahead behavior, consistency guarantees, and removal restrictions. Code length: The declarations are concise, and the documentation is justified by subtle API contracts, though annotations and verbose comments add some visual overhead. Action granularity: Each declaration and annotation occupies its own line; no actions are combined. Reading flow: The progression from peek() to next() to remove() naturally follows iterator usage. Minor formatting issues, such as the lack of blank lines around the import block and wrapped documentation links, slightly reduce readability.