Sample
int-165c88506e36-I09
Select one of ten low-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 | 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. The structure is clear: package declared first, then concise imports, followed by a well-documented interface. The interface is focused on a single responsibility (lookahead iteration), with three methods that logically extend Iterator. Nesting is minimal; only method signatures and Javadoc block nesting exist. The intent of each method is extremely clear from its name and comprehensive Javadoc, including edge cases and contracts. Code length is proportional to the documentation requirements — not unnecessarily verbose. Each action (peek, next, remove) is isolated, with one method per logical operation. Reading flow is natural: package→imports→type declaration→method declarations in logical order. Annotations like @ParametricNullness and @CanIgnoreReturnValue further clarify behavioral contracts without clutter. Nearly perfect readability.
Run 3
The code is highly readable due to its clear structure: a well-defined interface with logical method ordering and thorough Javadoc documentation. Nesting is minimal (only one interface level), and intent is unambiguous—the peeking behavior is explicitly described. Code length is appropriate, with no unnecessary methods or verbose logic. Action granularity is clean, with each method declaration on a single line and annotations clearly separated. Reading flow is natural, progressing from peek() to next() to remove(), which mirrors usage patterns. The only minor deductions are the presence of multiple annotations and Javadoc tags that slightly increase visual density, but they are essential for API clarity and correctness. Overall, this is exemplary code for a public API interface.
Run 1
Code Structure: A logically organized interface with imports, type documentation, and clearly separated method declarations. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive naming and precise documentation explain lookahead behavior, return guarantees, and removal constraints. Code length: The interface is concise; documentation is longer than the declarations but provides useful contract details rather than unnecessary repetition. Action granularity: Each method 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 documentation immediately preceding each declaration. Minor readability drawbacks include tightly grouped package/import statements and slightly awkward wrapping in the Javadoc link.
Run 2
Code Structure: The interface is logically organized, with imports, type documentation, and clearly separated method contracts. Nesting: There is only the interface scope, with no nested control flow. Clarity of intent: Descriptive names and precise Javadoc explain lookahead behavior, exceptions, and removal constraints. Code length: The declarations are concise; documentation adds length but appropriately clarifies API guarantees. 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 distractions include dense annotation usage, awkward wrapping in some Javadoc links, and the lack of a blank line between the package declaration and imports.
Run 3
Code Structure: A small, logically organized interface with related methods grouped clearly. Nesting: No nested control flow; declarations are flat and easy to scan. Clarity of intent: Descriptive names and precise Javadoc explain lookahead behavior, method guarantees, and removal restrictions. 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 operations. Reading flow: The progression from interface overview to peek(), next(), and remove() is natural. Minor distractions include densely wrapped Javadoc links and several annotations, but these do not materially hinder readability.