Sample
Remove comments and docstrings
| 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 |
Loading feature diagnosis…
| 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 | 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 |
|---|
The code is highly readable. It demonstrates clear logical organization by separating imports and defining a single, focused Protocol. Nesting is minimal, with no deep indentation or control flow. The intent—defining a structural type for objects with a `read` method—is explicit. Code length is concise; there is no redundancy. Action granularity is appropriate, with one definition per line. Reading flow is natural, following standard Python convention. Minor deductions are for the abstract nature of the code making it less immediately accessible to beginners, but for its purpose it is excellent.
The code is highly readable and follows modern Python best practices. Structure is clear: imports are logically grouped (future, stdlib, typing) with well-defined sections. Nesting is flat and minimal. Intent is unambiguous — defining a runtime-checkable protocol `SupportsRead` for objects with a `read` method. Code length is concise, with no redundancy; every import appears purposeful for this short snippet. Action granularity is appropriate: the protocol definition is a single clear unit. Reading flow is natural, moving from imports to the type definition. Minor deductions only for the slight verbosity of the typing imports relative to the small code body, though this is justified in a real project.
The code is highly readable. It uses clear, structured imports, organized with `from __future__` and `collections.abc`, then groups typing imports logically. The `SupportsRead` protocol is concise and uses `runtime_checkable` appropriately. It defines a single method with a clear purpose and a default `length` argument, using positional-only syntax for clarity. The generic `_T_co` is properly bound and covariant. Type aliases and `Protocol` are imported but unused, which slightly reduces focus, but this is minor. Overall, the code is flat, intent is unambiguous, lines are short, and flow is natural.
Code Structure: Imports and the protocol declaration are logically organized. Nesting: Minimal, with only a single method inside the class. Clarity of intent: SupportsRead and read clearly describe a readable-object interface, though _T_co is not defined in the snippet, leaving its type semantics unclear. Code length: The implementation is concise, but numerous unused imports add clutter. 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, class, and method is natural, although an additional blank line before the top-level class would improve visual separation.
Code Structure: Imports and the protocol declaration are logically organized, though many imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: SupportsRead and the typed read signature clearly describe a readable-object interface, but _T_co is undefined in the shown code, and protocol syntax requires typing familiarity. Code length: The interface is concise, although the import list is disproportionately long. Action granularity: Each declaration occupies its own logical line; the one-line method stub is appropriate for a protocol. Reading flow: The progression from imports to decorator, class, and method is natural, though additional spacing before the top-level class would improve visual separation.
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 clearly describes a read-capable interface, and annotations express the method contract; however, _T_co is undefined, obscuring its intended type and covariance. Code length: The implementation is concise, but unused imports add clutter. 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 interface is natural, although another blank line before the top-level class would improve conventional formatting.