Sample
pyint-2bc28b0c1661-SRC
Unmodified source class
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 | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.33 | 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 due to its clear and logical structure. It cleanly separates imports into standard library and typing-specific groups, avoiding unnecessary clutter. The use of `from __future__ import annotations` and consolidated typing imports shows good organization. Nesting is flat, with no deeply indented blocks. The intent of defining a runtime-checkable protocol for readable objects is concise and unambiguous. Code length is minimal, achieving its goal without verbosity. Action granularity is clear, with each import and the protocol definition on separate lines. Reading flow is natural, progressing from imports to the protocol definition. Minor deductions: some might find the grouped typing imports slightly dense, and the `...` default for `length` could be clarified with a comment, but overall this is exemplary, idiomatic Python.
Run 2
The code is highly readable. It uses modern Python features (PEP 585, PEP 604) via `from __future__ import annotations`, which reduces verbosity. Imports are logically grouped: standard library collections, typing module, and TYPE_CHECKING. The `runtime_checkable` decorator and `Protocol` are used correctly and clearly. Naming is descriptive (`SupportsRead`, `_T_co`). The Protocol method signature is concise, uses positional-only parameter (`/`) and default ellipsis (`...`) appropriately. The code is flat, with no unnecessary nesting. Each import and definition occupies its own line, maintaining one-action-per-line. Reading flow is natural, from imports to class definition. The only minor omission is a docstring for the Protocol, which would clarify intent further, but the name and structure already convey the purpose clearly.
Run 3
The code is highly readable due to clear modular structure, flat organization, and explicit intent. Imports are logically grouped and modern typing features (e.g., Protocol, TypeAlias) are used appropriately. The SupportsRead protocol is concise, with a single well-defined method and clear parameter semantics. Nesting is minimal, action granularity is one meaningful definition per block, and the reading flow is natural. Minor deductions: the ellipsis default for 'length' and the forward slash positional-only marker may require some familiarity with advanced typing, slightly reducing accessibility for less experienced readers.
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: SupportsRead and read clearly describe a readable-object interface, but the undeclared _T_co and specialized typing syntax require context. Code length: The implementation is concise, although the imports outweigh the actual declaration. Action granularity: Each statement has a single purpose; the inline ellipsis is a compact, conventional protocol stub. Reading flow: The progression from imports to decorator, class, and method is natural, with minor friction from the missing type-variable definition.
Run 2
Code Structure: Imports and the protocol declaration are logically organized, but _T_co is not defined in the snippet and several imports are unused. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: SupportsRead and read clearly describe a readable-object interface, although generic typing and positional-only syntax require familiarity with Python typing. Code length: The declaration is concise, but unused imports add unnecessary length. Action granularity: Each statement serves a single purpose; the compact method stub is appropriate for a protocol. Reading flow: The progression from imports to interface definition is natural, though an extra blank line before the top-level class would improve formatting.
Run 3
Code Structure: Imports and the protocol definition are logically organized, though several imports appear unused. Nesting: Minimal, with only a single method inside the class. Clarity of intent: SupportsRead and its typed read method clearly describe a readable-object interface, but _T_co is not defined in the snippet, leaving its type parameter unclear. Code length: The implementation is concise, although the import list is disproportionate to the shown functionality. Action granularity: Each statement serves one purpose; the one-line method declaration is appropriate for a protocol stub. Reading flow: Generally natural, moving from imports to the interface definition, but the missing type-variable declaration and limited spacing before the class slightly interrupt readability.