Sample
pyint-cc19994d5566-I05
Rewrite eligible decimal integer literals in hexadecimal notation
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.33 | 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 due to its clear organization, flat structure, and explicit intent. It uses modern Python typing features, logical imports, and a concise protocol definition. The single method with a clear return type makes the purpose unambiguous, and each element is placed with precision, enhancing natural reading flow.
Run 3
The code is highly readable. It has a clear, logical structure: a future import, followed by grouped standard library and typing imports. The `Protocol` class is concise and focused, with a single, well-named method that clearly expresses its intent. Nesting is minimal. Each line performs one clear action (import, decorator, method definition). The use of type variables and a runtime-checkable protocol demonstrates modern Python typing practices, making the contract explicit. Only the `TypeAlias` import is unused, which slightly detracts from perfection but does not harm readability.
Run 1
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 an interface, but _KT_co and _VT_co are undefined in the provided code, obscuring the generic parameters. Code length: The implementation is concise, although the import list is larger than necessary. Action granularity: Each statement has a single purpose; the one-line method stub is appropriate for a protocol. Reading flow: The progression from imports to decorator to interface is natural, but additional spacing before the class and visible type-variable definitions would improve readability.
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, its return annotation, and runtime_checkable clearly express a structural interface for objects with an items method; however, _KT_co and _VT_co are not defined in the snippet, leaving their meaning incomplete. Code length: The implementation is concise, although many imports are unused in the provided code. Action granularity: Each statement serves a single purpose; the inline ellipsis is conventional for protocol methods. Reading flow: The progression from imports to interface definition is natural, but an additional blank line before the decorator and removal of unused imports would improve presentation.
Run 3
Code Structure: imports followed by a protocol definition are logically organized, though the referenced type variables are not defined in the snippet and several imports are unused. Nesting: minimal, with only one method inside the class. Clarity of intent: SupportsItems and the typed items signature clearly describe an interface for iterable key-value pairs; undeclared type variables weaken self-contained clarity. Code length: the protocol is concise, but unused imports add clutter. Action granularity: each statement occupies its own line, and the inline ellipsis is conventional for protocol methods. Reading flow: natural top-to-bottom progression, although an additional blank line before the top-level class would improve formatting.