Sample
pyint-5d304c1337dd-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.405 | 0–1; higher is more readable |
| Dorn | 0.918 | 0–1; higher is more readable |
| Mi | 0.496 | 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 | 17 | 0–20; mean of three runs |
| BTTF | 0.837 | 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.853 | −7.279 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 144.754 | −4.777 |
| Source linesThe number of non-empty source lines. | 7 | +2.8 |
Intercept 8.87 + feature contributions = -0.386 (log-odds).
Score = sigmoid(-0.386) = 0.405.
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. | 59.875 | +1.129 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 8 | +0.753 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.024 | +0.713 |
| 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. | 6.705 | −0.316 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 60 | +0.164 |
Intercept 0.07 + feature contributions = 2.416 (log-odds).
Score = sigmoid(2.416) = 0.918.
| Score | 0.496 |
|---|
| Score | 6 |
|---|
Run 1
The code is well-structured and highly readable. It uses a clear import block with forward compatibility and type-checking support. Class definition is concise with a docstring that clearly states intent. Nesting is virtually nonexistent, and each import/logical action is on its own line. One minor deduction for lack of context: the class is empty but inherits from `RequestException`, and `CompatJSONDecodeError` import is not used in the shown snippet, making purpose slightly ambiguous without surrounding code. Overall, very clean.
Run 2
The code is highly readable due to its logical structure, flat nesting, and clear intent. It cleanly separates imports (future, typing, third-party, local) and defines a single-purpose exception class. The class is concise, with a clear docstring that immediately explains its purpose. Action granularity is appropriate—one action per line effectively. Reading flow is natural and predictable. Minor deduction only because the import of `RequestException` is implicit (not shown), which could slightly obscure the inheritance context for a reader without surrounding file knowledge.
Run 3
The code is highly readable. It has a clear, logical structure: future import for compatibility, typing imports for type hints, external library exception import, internal compatibility import, and a single well-defined exception class. Nesting is nonexistent, as the class definition is flat and focused. The intent is unambiguous — defining an HTTP error exception class with a clear docstring. Code length is concise, without unnecessary boilerplate. Each import is on its own line, and the class definition is minimal, adhering to one action per line. The reading flow is natural, moving from general imports to specific ones, then to the class definition. Minor deductions: the class lacks methods or additional context (e.g., status code attributes), and the aliased imports (BaseHTTPError, CompatJSONDecodeError) could be slightly confusing without seeing their usage. However, the code is clean, idiomatic Python.
Run 1
Code Structure: Imports followed by a single exception class provide straightforward organization. Nesting: No nested logic makes the snippet easy to scan. Clarity of intent: The class name and docstring clearly identify an HTTP exception, although RequestException is not defined or imported in the snippet. Code length: Very concise, but several imports appear unused and introduce unnecessary noise. Action granularity: Each import and declaration occupies its own line. Reading flow: The top-to-bottom flow is natural, though an additional blank line before the top-level class would improve conventional Python formatting.
Run 2
Code Structure: Imports precede a clearly separated exception class, providing logical organization. Nesting: There is no nested control flow, and the class body is minimal. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but RequestException is not defined or imported in the snippet, and the unused imports add ambiguity. Code length: The class is concise, although several imports appear unnecessary for the code shown. Action granularity: Each import and declaration occupies its own line, making individual actions easy to distinguish. Reading flow: The snippet reads naturally from dependencies to declaration, though an additional blank line before the top-level class would improve conventional formatting.
Run 3
Code Structure: Imports followed by a small exception class provide a logical organization, although RequestException is not defined or imported in the snippet. Nesting: Only the class body is nested, making the code easy to scan. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but the unused imports and unresolved base class reduce contextual clarity. Code length: The class is concise, though several imports appear unnecessary within the provided code. Action granularity: Each import, declaration, and docstring occupies its own line. Reading flow: The top-to-bottom flow is natural; additional spacing between imports and the class would improve visual separation.