Sample
pyint-5ac70d007478-SRC
Unmodified source class
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 | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.67 | 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 highly readable due to its clean structure, minimal nesting, and clear intent. It defines a runtime-checkable protocol with a single, well-documented method, using modern typing syntax. The imports are logically grouped from `__future__`, `collections.abc`, and `typing`, improving clarity. The protocol is concise and focused, avoiding unnecessary complexity. Action granularity is appropriate, with each significant operation on its own line. The reading flow is natural, progressing from imports to type definitions. Minor deductions include the ellipsis-only body potentially requiring familiarity with typing protocols, but overall the code is excellent.
Run 2
The code is well-structured and highly readable for a type-oriented Python snippet. It logically groups imports by source (future, abc, typing) and uses modern typing constructs (TypeAlias, Protocol, TypeVar) clearly. Nesting is minimal—only one level in the Protocol method. Intent is unambiguous: define a runtime-checkable protocol for objects with an `items()` method. Length is concise with no redundancy. Action granularity is appropriate, with the single method definition on its own line. Reading flow is natural, from imports to protocol definition. Minor deductions: import grouping could separate `typing` items more granularly, and the ellipsis-only method body, while standard for Protocol, may be slightly unclear to novices.
Run 3
The code demonstrates excellent readability. Structure is logical, grouping imports by type (future, collections.abc, typing) and clearly separating the protocol definition. Nesting is flat, with only one level of indentation for the protocol method. Intent is clear — defining a runtime-checkable protocol for objects that support .items(), likely for generic mapping-like types. Length is concise, avoiding unnecessary verbosity while including all necessary imports and type parameters. Action granularity is appropriate, with each line performing a distinct conceptual action. Reading flow is natural, starting with imports then the protocol definition, with type variables declared before use. The use of modern typing features (Protocol, runtime_checkable, TypeAlias, type variables) is idiomatic and enhances clarity for maintainers familiar with type hints.
Run 1
Code Structure: Imports and a small protocol definition are logically organized, though several imports are unused in this snippet. Nesting: Minimal nesting keeps the code easy to scan. Clarity of intent: SupportsItems and its typed items method clearly describe an interface for iterable key-value pairs; however, _KT_co and _VT_co are not defined in the provided code, obscuring the generic type setup. Code length: Concise overall, with some unnecessary import overhead. Action granularity: Each statement has a single purpose; the inline ellipsis is conventional for protocol methods. Reading flow: Natural progression from imports to decorator, class, and method, although additional spacing before the class would improve visual separation.
Run 2
Code Structure: Imports and the protocol declaration are logically organized. Nesting: Minimal nesting makes the snippet easy to scan. Clarity of intent: SupportsItems clearly describes an interface for objects exposing items(), and the return annotation specifies key-value pairs. However, _KT_co and _VT_co are not defined in the provided snippet, leaving their type roles incomplete. Code length: The implementation is concise, though numerous unused imports add clutter. Action granularity: Each statement has a distinct purpose; the inline ellipsis is conventional for protocol methods. Reading flow: The progression from imports to decorator, class, and method is natural, but an additional blank line before the class would improve visual separation.
Run 3
Code Structure: Imports precede a clearly isolated protocol definition, providing logical organization. Nesting: Minimal nesting makes the snippet easy to scan. Clarity of intent: SupportsItems and its typed items method clearly express the interface, but the undefined _KT_co and _VT_co type variables obscure context and make the snippet incomplete. Code length: The implementation is concise, although many imports are unused in the shown code. Action granularity: Each statement has a distinct purpose; the one-line method stub is appropriate for a protocol. Reading flow: The flow from imports to decorator to interface is natural, though additional spacing before the class and removal of unused imports would improve readability.