Sample
pyint-55681adba177-I05
Rewrite eligible decimal integer literals in hexadecimal notation
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 | 16 | 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 demonstrates excellent readability. It is logically structured with a clear separation of imports, using both a `from __future__` import and the `collections.abc` and `typing` modules appropriately. Nesting is minimal and flat. The intent is unambiguous: defining a runtime-checkable `Protocol` named `SupportsRead` with a clear method signature. The code is concise, containing no unnecessary lines. Action granularity is one action per line, especially in the method signature. The reading flow is natural, with imports at the top and the class definition following. The only minor potential deduction is the use of advanced typing features (e.g., `Protocol`, `TypeAlias`, `TypeVar`) which may be less familiar to some readers, but for its intended purpose, this code serves as a model of clarity.
Run 3
The code is highly readable. It uses clear imports from `collections.abc` and `typing`, demonstrating an explicit intent to support type hints and static analysis. The structure is logical: imports are grouped, then a single protocol class is defined. The protocol `SupportsRead` is well-named, uses a TypeVar for generic return typing, and includes a clear `read` method signature. Nesting is nonexistent, action granularity is clean, and the code is concise. The only minor deduction is that a brief docstring or comment on the protocol’s purpose would further aid clarity, and the use of `...` as a default for `length` may not be immediately obvious to all readers.
Run 1
Code Structure: Imports and the protocol declaration are logically organized. Nesting: Only the necessary class-method nesting is present. Clarity of intent: SupportsRead and its typed read method clearly describe a readable-object interface, although the undeclared _T_co makes the snippet harder to interpret independently. Code length: The implementation is concise, but several imports are unused in the provided snippet. Action granularity: Each statement serves a single purpose; the one-line method stub is appropriate for a protocol. Reading flow: The progression from imports to decorator, class, and method is natural, though an additional blank line before the top-level class would improve visual separation.
Run 2
Code Structure: Imports are grouped logically, followed by a focused protocol definition, although _T_co is not defined in the snippet and several imports are unused. Nesting: Minimal, with only one method inside the class. Clarity of intent: SupportsRead clearly describes a read-capable interface, but the undeclared type variable and specialized typing syntax reduce immediate clarity. Code length: The implementation is concise, though the import list is excessive for the code shown. Action granularity: Each statement has a distinct purpose; the compact method signature is appropriate for a protocol stub. Reading flow: The progression from imports to decorator, class, and method is natural, but an additional blank line before the top-level class and a visible type-variable declaration would improve readability.
Run 3
Code Structure: Imports and the protocol definition are logically organized, though several imports are unused in this snippet. Nesting: Minimal, with only a class and its method. Clarity of intent: SupportsRead and read clearly describe a readable-object interface, but the undefined _T_co obscures the generic type setup. Code length: The implementation is concise, although the import list is disproportionately large. Action granularity: Each line has a single purpose; the inline method stub is appropriate for a protocol. Reading flow: Straightforward from imports to interface, but the missing type-variable declaration interrupts understanding, and an additional blank line before the class would improve visual separation.