Sample
int-32b232318ada-I08
Select one of ten high-readability unrelated code templates per class
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 | 17.67 | 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. It has a clear, logical structure with a single interface definition, minimal nesting, and well-documented methods. Javadoc comments clearly explain intent, especially the non-obvious interactions between peek(), next(), and remove(). The use of annotations (@ParametricNullness, @CanIgnoreReturnValue, @DoNotMock) adds useful context without clutter. The method signatures are concise and each action is separated appropriately. The reading flow is natural, following the iteration lifecycle. Only minor deductions for the slightly dense Javadoc in places and the use of several annotations that may require domain knowledge.
Run 3
The code is highly readable. It has a clear, logical structure as a single interface with well-defined methods. Nesting is minimal. Each method's intent is clearly documented with Javadoc, including edge cases and exceptions. Code length is concise, focused on the contract, not implementation. Action granularity is appropriate, with one method declaration per section. Reading flow is natural, following standard Java conventions and Guava style. Minor deductions: the Javadoc is somewhat verbose for such a small interface, and the generic bound with @Nullable adds slight complexity, but neither significantly harms readability.
Run 1
Code Structure: A well-organized interface groups three closely related iterator operations, each with its documentation and annotations. Nesting: Flat declarations with no nested control flow make scanning easy. Clarity of intent: Descriptive method names and precise Javadoc explain lookahead behavior, return guarantees, and removal restrictions. Code length: The interface is concise; its longer documentation provides useful contract details rather than unnecessary implementation complexity. Action granularity: Each method declaration and annotation occupies its own line, with no combined actions. Reading flow: The sequence from peek() to next() to remove() follows natural iterator usage. Minor distractions include densely wrapped Javadoc links and the lack of spacing between the package and import sections.
Run 2
Code Structure: The interface is logically organized, with imports, interface documentation, and clearly separated method contracts. Nesting: There is no control-flow nesting, only the interface scope. Clarity of intent: Descriptive naming and detailed Javadoc make lookahead behavior, nullness, and removal constraints explicit. Code length: The declarations are concise; documentation is substantial but justified for an API contract. Action granularity: Each declaration and annotation occupies its own line, with no compressed operations. Reading flow: Methods follow a natural peek-next-remove sequence, and formatting is consistent. Minor readability drawbacks include awkward wrapping in Javadoc links, annotation density, and the lack of a blank line between the package declaration and imports.
Run 3
Code Structure: The interface is logically organized, with imports, interface documentation, and clearly separated method declarations. Nesting: Minimal nesting and no control flow make it easy to scan. Clarity of intent: Descriptive names and precise Javadoc explain lookahead behavior, method relationships, and removal constraints. Code length: Concise declarations are supported by useful documentation rather than unnecessary implementation detail. Action granularity: Each declaration and annotation occupies its own line; no unrelated operations are combined. Reading flow: The progression from peek() to next() to remove() naturally presents the API contract. Minor distractions include densely wrapped Javadoc links, stacked annotations, and the lack of a blank line between the package declaration and imports.