Sample
int-e6cff03bbbff-I12
Inline all eligible single-use intermediate local variables
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
This code is highly readable. It is a well-structured interface with clear Javadoc documentation explaining the contract for each method. The nesting is minimal and appropriate, the intent of the PeekingIterator is immediately obvious, and the code is concise. Each method declaration is on its own line with clear annotations. The reading flow is natural, starting with imports, then documentation, then method declarations in a logical order. The only minor issue is the slight complexity of the annotations, which might be unfamiliar to some readers, but this is standard for Guava and does not detract from readability.
Run 3
The code is highly readable with clear structure and intent. It follows standard Java interface conventions with well-organized imports, meaningful annotations, and comprehensive Javadoc. The interface is concise with only three methods, each having a single clear purpose. Nesting is minimal and the code flows naturally. Javadoc is thorough and helpful, particularly for the nuanced behavior of peek() and remove(). Minor deductions: the multiline @throws alignment in the peek() Javadoc is slightly awkward, and there is no blank line after the @CanIgnoreReturnValue import before the java.util imports. Overall this is exemplary production-quality code that clearly communicates its contract to implementers.
Run 1
Code Structure: A well-organized interface with imports, class documentation, and clearly separated method declarations. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and precise documentation explain lookahead behavior, return guarantees, and removal restrictions. Code length: Concise declarations; the longer comments provide useful API-contract details rather than unnecessary verbosity. Action granularity: Each declaration and annotation occupies its own line, making individual elements easy to identify. Reading flow: Methods progress naturally from peek() to next() to remove(), with relevant documentation immediately preceding each. Minor distractions include tightly packed package/import formatting and awkward wrapping in the documentation link.
Run 2
Code Structure: The interface is logically organized, with imports, interface documentation, and clearly separated method declarations. Nesting: There is no nested control flow; the structure is flat and easy to scan. Clarity of intent: Descriptive naming and precise Javadoc explain lookahead behavior, exception conditions, and interactions between peek(), next(), and remove(). Code length: The declarations are concise; documentation is extensive but justified by subtle behavioral contracts. 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() is natural. Minor readability costs include dense annotations and awkward wrapping of some Javadoc links.
Run 3
Code Structure: The interface is logically organized, with imports, interface documentation, and related method declarations clearly separated. Nesting: There is only the interface scope, with no nested control flow. Clarity of intent: Descriptive names and precise Javadoc explain lookahead behavior, guarantees, and removal restrictions. Code length: The declarations are concise; the longer documentation provides useful API-contract details rather than unnecessary verbosity. Action granularity: Each annotation and method declaration occupies its own line, with no combined actions. Reading flow: The progression from peek() to next() to remove() is natural. Minor distractions include the awkwardly wrapped documentation link, annotation density, and the lack of a blank line between the package declaration and imports.