Sample
pyint-21509da6ce7b-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.023 | 0–1; higher is more readable |
| Dorn | 0.462 | 0–1; higher is more readable |
| Mi | 0.512 | 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 | 15.67 | 0–20; mean of three runs |
| BTTF | 0.678 | 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. | 330.619 | −10.91 |
| 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.88 | −7.319 |
| Source linesThe number of non-empty source lines. | 14 | +5.6 |
Intercept 8.87 + feature contributions = -3.76 (log-odds).
Score = sigmoid(-3.76) = 0.023.
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.805 | −0.217 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.106 | −0.086 |
Intercept 0.07 + feature contributions = -0.152 (log-odds).
Score = sigmoid(-0.152) = 0.462.
| Score | 0.512 |
|---|
| Score | 6 |
|---|
Run 1
The code is highly readable. It has a clear, logical structure with imports organized by standard library modules and typing utilities. Nesting is essentially flat — the only indented block is a minimal Protocol method definition. Intent is explicit: it defines a runtime-checkable structural protocol for objects with a `read` method. The code is concise, avoiding any unnecessary verbosity. Action granularity is appropriate, with each import grouping and the Protocol definition on separate logical lines. Reading flow is natural, from future imports down to the protocol definition. The only minor deduction is that the lengthy import block could be slightly streamlined, but it is well-organized and conventional.
Run 2
The code is highly readable due to its clear structure and modern Python typing practices. It uses a logical import organization, separating future annotations, standard library collections, and typing utilities. The Protocol definition is concise, with a single well-defined method and appropriate use of TypeVar. The runtime_checkable decorator and positional-only parameter syntax show intent clearly. The only minor drawback is the slightly verbose import block, but this is justified for maintaining explicit type annotations.
Run 3
The code is highly readable due to its clear logical organization: imports are grouped semantically (future, collections, typing), and the `SupportsRead` protocol is defined concisely with a single, well-documented method. Nesting is minimal; the only indentation is inside the class method, which is standard. Intent is obvious—defining a runtime-checkable protocol for objects with a `read` method—enhanced by the use of `Protocol` and `runtime_checkable`. There is no unnecessary length; each line is purposeful. Action granularity is consistently one action per line. The reading flow is natural, from imports to definition, with sensible type variable naming (`_T_co` for covariant return). Slight deductions: the `...` default and `/` positional-only marker add minor cognitive overhead, and `TYPE_CHECKING` is imported but unused, hinting at incomplete context. Overall, the code is clean, idiomatic, and accessible to anyone familiar with Python typing.
Run 1
Code Structure: Imports and the protocol definition are logically organized, though several imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: SupportsRead and its typed read method clearly describe a readable-object interface, but the undefined _T_co leaves its generic type unclear. Code length: The implementation is concise, although the import list is disproportionately large for the shown code. Action granularity: Each statement serves a single purpose; the inline ellipsis is conventional for a protocol method. Reading flow: The progression from imports to decorator, class, and method is natural, but additional blank-line separation before the class would improve presentation.
Run 2
Code Structure: Imports precede a focused protocol definition, providing logical organization, though several imports appear unused. Nesting: Minimal nesting makes the snippet easy to scan. Clarity of intent: SupportsRead clearly represents objects with a read method, but _T_co is undefined in the provided code, obscuring the generic return type. Code length: The protocol is concise, while the unused imports add unnecessary clutter. Action granularity: Each statement has a single purpose; the inline ellipsis is conventional for protocol methods. Reading flow: The progression from imports to decorator, class, and method is natural, although the missing type-variable declaration and limited spacing before the class interrupt clarity.
Run 3
Code Structure: Imports and the protocol definition are logically organized, although several imports are unused in this snippet. Nesting: Minimal nesting keeps the code easy to scan. Clarity of intent: SupportsRead clearly represents a read-capable interface, but the undefined _T_co obscures its generic return type, and Protocol syntax requires typing familiarity. Code length: The implementation is concise, though the broad import list adds unnecessary bulk. Action granularity: Each line generally expresses a single declaration or import element; the one-line method signature and stub remain readable. Reading flow: The sequence from imports to decorator to class is natural, but the missing type-variable declaration interrupts understanding, and additional spacing before the top-level class would improve presentation.