Sample
pyint-e77483ee28b1-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.824 | 0–1; higher is more readable |
| Dorn | 0.916 | 0–1; higher is more readable |
| Mi | 0.472 | 0–1; higher is more readable |
| LLOC | 6 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.33 | 0–20; mean of three runs |
| BTTF | 0.85 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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.855 | −7.282 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 146.719 | −4.842 |
| Source linesThe number of non-empty source lines. | 12 | +4.8 |
Intercept 8.87 + feature contributions = 1.546 (log-odds).
Score = sigmoid(1.546) = 0.824.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 60 | +1.124 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.015 | +0.797 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 13 | +0.576 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 7 | −0.495 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 11.639 | −0.247 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 59.923 | +0.162 |
Intercept 0.07 + feature contributions = 2.385 (log-odds).
Score = sigmoid(2.385) = 0.916.
| Score | 0.472 |
|---|
| Score | 6 |
|---|
Run 1
The code is highly readable with a clear, logical structure. It imports only necessary components, groups them logically (standard typing, third-party, local), and defines a single, well-named exception class. Nesting is non-existent, and the class purpose is explicit through a descriptive name and a succinct docstring that explains what the error represents and how to catch it. Code length is minimal and appropriate, with one action per line where applicable. Reading flow is natural: imports, then class definition, then documentation. Minor points deducted only because the class body is entirely documentation with no custom logic, which might initially confuse some readers about its necessity, though this is common for exception classes. Overall, it adheres well to clean-code principles.
Run 2
The code is clean, well-structured, and follows Python best practices. It uses `from __future__ import annotations` for forward compatibility and separates imports by type (`TYPE_CHECKING`, `Any`) and third-party modules. The class `Timeout` inherits from `RequestException`, and the docstring clearly explains the purpose and what errors it covers, with proper Sphinx references. There is no nesting, and each line performs a single action. The reading flow is natural: imports, then class definition, then documentation. The only minor deductions are for the slightly verbose import of `JSONDecodeError` and the fact that the code is a small snippet, which makes it hard to evaluate deeper structural complexity. Overall, it is highly readable and maintainable.
Run 3
The code is clean, well-structured, and clearly readable. It uses proper imports with `from __future__ import annotations` for forward compatibility, and type-checking imports are correctly guarded with `TYPE_CHECKING`. The class definition is concise and purposeful, with a clear docstring explaining its purpose and relationship to other exceptions. The code is flat with no nesting, and each import/statement is on its own line, maintaining good action granularity. The reading flow is natural — imports first, then class definition with a helpful docstring. Minor deductions: the unused `Any` import and slight ambiguity around the unused `BaseHTTPError` and `CompatJSONDecodeError` imports (possibly re-exported or used elsewhere, but not evident here). Overall, the code follows Python best practices and is highly maintainable.
Run 1
Code Structure: Imports followed by a single exception class provide clear organization, although RequestException is not defined or imported in this snippet. Nesting: Minimal, with only the class body. Clarity of intent: The descriptive class name and docstring clearly explain the timeout exception and what catching it covers. Code length: Very concise, though several imports are unused in the displayed code. Action granularity: Each import and declaration occupies its own line. Reading flow: Natural top-to-bottom progression; an additional blank line between imports and the class would improve visual separation.
Run 2
Code Structure: Imports followed by an exception class form a simple, logical organization, though RequestException is not defined or imported in the snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name and docstring clearly identify a timeout exception and explain which related errors catching it covers. Code length: Very concise, although the displayed imports are unused within this snippet. Action granularity: Each import and declaration occupies its own line, with no compressed operations. Reading flow: The top-to-bottom flow is natural; clearer spacing between import groups and before the class would improve readability.
Run 3
Code Structure: Imports precede a focused exception class, providing logical organization, though RequestException is not defined or imported in the snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name and docstring clearly describe a timeout exception and its related subclasses. Code length: Concise, but several imports appear unused in this excerpt. Action granularity: Each import and declaration occupies its own line, avoiding compressed actions. Reading flow: Natural top-to-bottom flow, with minor distractions from unused imports and the missing base-class context.