Sample
pyint-da363a7ee51f-I13
Lower every eligible synchronous for loop to a while loop
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.019 | 0–1; higher is more readable |
| Dorn | 0.487 | 0–1; higher is more readable |
| Mi | 0.483 | 0–1; higher is more readable |
| LLOC | 6 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.693 | 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. | 336.045 | −11.089 |
| 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.883 | −7.325 |
| Source linesThe number of non-empty source lines. | 14 | +5.6 |
Intercept 8.87 + feature contributions = -3.944 (log-odds).
Score = sigmoid(-3.944) = 0.019.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 15 | +0.505 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 14 | −0.253 |
| 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. | 81 | +0.234 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 13.78 | −0.217 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.095 | +0.015 |
Intercept 0.07 + feature contributions = -0.052 (log-odds).
Score = sigmoid(-0.052) = 0.487.
| Score | 0.483 |
|---|
| Score | 6 |
|---|
Run 1
The code is concise, well-structured, and purpose-driven. It uses a clear Protocol definition with runtime checkability, proper generic type variables, and a self-explanatory method signature. Imports are organized and minimal, with future annotations for compatibility. Nesting is absent, and action granularity is one concept per line. The only minor drawbacks are reliance on implicit conventions (underscore naming for type vars) and slight verbosity in import grouping, which could affect beginners.
Run 2
The code is highly readable. It demonstrates clear structure with logical import grouping and explicit type annotations. The nesting is flat, the intent is unambiguous (defining a runtime-checkable protocol for objects with an items method), and the length is concise. Each import and the method signature occupy their own line, supporting one action per line. The reading flow is natural, moving from future imports to standard library imports, then to typing utilities, and finally the protocol definition. Minor deductions: the Protocol type variables (_KT_co, _VT_co) could benefit from a brief comment explaining their covariance, and the ellipsis-only method body, while idiomatic, may not be immediately clear to developers unfamiliar with Protocol definitions.
Run 3
The code is highly readable. It clearly groups imports from the same module, uses modern Python 3.11+ syntax (`from __future__ import annotations`, `TypeAlias`), and defines a single, well-focused protocol with a precise name (`SupportsItems`). The type variables `_KT_co` and `_VT_co` follow standard conventions, and the protocol’s single method has a clear purpose and return type. There is no nesting or ambiguous logic. The only minor deduction is that the unused `Callable`, `Mapping`, `MutableMapping`, `Sequence`, and `Any` imports could be trimmed for brevity, but this does not significantly impact readability.
Run 1
Code Structure: Imports and a single protocol declaration are logically organized, although several imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: SupportsItems and its typed items method clearly describe an interface, but undefined type variables _KT_co and _VT_co leave the snippet incomplete and require outside context. Code length: Concise overall, with some unnecessary import overhead. Action granularity: Each statement has a distinct purpose; the inline ellipsis is conventional for protocol methods. Reading flow: Natural progression from imports to decorator, class, and method, though additional spacing before the top-level class would improve visual separation.
Run 2
Code Structure: Imports followed by a protocol definition provide clear, logical organization. Nesting: Minimal nesting keeps the snippet easy to scan. Clarity of intent: SupportsItems and the annotated items method clearly describe an interface for iterable key-value pairs, though _KT_co and _VT_co are not defined in the snippet. Code length: The implementation is concise, but several imports appear unused. Action granularity: Each statement has a single purpose; the inline ellipsis is conventional for protocol methods. Reading flow: The progression from imports to decorator to interface is natural, although an additional blank line before the top-level class would improve formatting.
Run 3
Code Structure: Imports and the protocol declaration are logically organized, though several imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: SupportsItems and its typed items method clearly describe the intended interface, but _KT_co and _VT_co are not defined in the provided code, reducing self-contained clarity. Code length: The declaration is concise, while the unused imports add unnecessary length. Action granularity: Each statement serves a distinct purpose; the one-line method stub is appropriate for a protocol. Reading flow: The progression from imports to decorator, class, and method is natural, although an additional blank line before the top-level class would improve visual separation.