Sample
pyint-f2dadbd970d7-I10
Deterministically remove some optional blank lines and bracketed line breaks
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.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.67 | 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 concise and well-structured with clear imports and a simple class definition. It uses modern Python features (from __future__ import annotations) and explicit typing. The class has a clear docstring explaining its purpose. However, the code is incomplete/incomplete context — 'RequestException' is not defined within the snippet, and the imported exceptions (BaseHTTPError, CompatJSONDecodeError) are unused, which slightly reduces clarity of intent. Nesting is flat, action granularity is one per line, and reading flow is natural. Minor deductions for unused imports and undefined base class in the excerpt.
Run 3
The code is concise and logically structured, with a clear purpose: defining an HTTPError exception class. It uses modern Python features like `from __future__ import annotations` and explicit type-checking imports, which improve maintainability. Import organization is flat and grouped logically (standard library, third-party, local), aiding reading flow. The class definition is minimal, with a one-line docstring that clearly states intent. Nesting is non-existent, and action granularity is appropriate—each import and the class definition occupy their own line. The only minor drawback is that the class body is empty (using only a docstring), which might make its behavior slightly ambiguous without context, but this is common for exception classes. Overall, it is highly readable, with no unnecessary complexity or tangling.
Run 1
Code Structure: Imports precede a clearly separated exception class, providing logical organization. Nesting: The code is flat, with only the class body indented. 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 imported aliases are unused. Code length: The class is concise, although several imports appear unnecessary in isolation. Action granularity: Each import and declaration occupies its own line. Reading flow: The top-to-bottom flow is natural, though another blank line before the top-level class would improve conventional Python formatting.
Run 2
Code Structure: Imports followed by a single exception class provide straightforward organization, though RequestException is not defined or imported in the snippet. Nesting: No nested control flow; the class body is minimal. Clarity of intent: The class name and docstring clearly identify an HTTP-related exception, but the unused imports obscure the snippet’s dependencies and purpose slightly. Code length: Very concise, although several imports appear unnecessary in isolation. Action granularity: Each import and declaration occupies its own line. Reading flow: Natural top-to-bottom progression, with minor readability drawbacks from the unresolved base class and limited spacing between imports and the class.
Run 3
Code Structure: Imports followed by a class definition provide a logical organization, although RequestException is not defined or imported in the snippet. Nesting: Minimal, with only a class-level docstring. Clarity of intent: The HTTPError name and docstring clearly identify a specialized exception, but the unused BaseHTTPError import can create ambiguity about its relationship to this class. Code length: Very concise, though several imports appear unnecessary in isolation. Action granularity: Each import and declaration occupies its own line. Reading flow: Straightforward from dependencies to definition; separating standard-library, third-party, and local imports and adding another blank line before the class would improve readability.