Sample
Split eligible integer literals into pairs of short-named intermediate variables
| 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 | 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 |
Loading feature diagnosis…
| 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 | 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 |
|---|
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.
The code is concise and structured logically, with clear imports and a well-defined class with a docstring. It uses modern Python features (annotations, TYPE_CHECKING) and avoids unnecessary complexity. Nesting is absent, actions are separated cleanly, and intent is obvious. The only minor drawback is the slightly redundant import of JSONDecodeError, which is unused in the snippet, but this does not significantly harm readability.
The code is concise, logically structured, and clearly imports only what's needed. It uses good practices like `from __future__ import annotations` and TYPE_CHECKING. The class definition is minimal with a clear docstring. Minor deductions for leaving `Any` unused and the naming of `BaseHTTPError` which could be clearer about its role. Overall, highly readable.
Code Structure: Imports precede a simple exception class, giving the snippet a logical organization, though RequestException is not defined or imported here. Nesting: No unnecessary nesting. Clarity of intent: The class name and docstring clearly identify an HTTP error, but the unused imports obscure their relevance. Code length: Very short, although several imports appear unnecessary within this snippet. Action granularity: Each import and declaration occupies its own line. Reading flow: Straightforward top-to-bottom flow; an additional blank line before the top-level class would improve conventional Python formatting.
Code Structure: Imports precede a clearly defined exception class, providing straightforward organization. Nesting: No nested control flow; only a class body. Clarity of intent: The class name and docstring clearly identify an HTTP-related exception, though RequestException is not defined or imported in the snippet. Code length: Very concise, but several imports appear unused within the shown code. Action granularity: Each statement occupies its own line. Reading flow: Natural top-to-bottom progression, although an additional blank line before the top-level class would improve conventional Python formatting.
Code Structure: Imports precede a clearly defined 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 error, but RequestException is not defined or imported in the snippet, and several imports have no visible use. Code length: Very concise, without unnecessary implementation. Action granularity: Each import and declaration occupies its own line. Reading flow: Natural top-to-bottom progression, though grouping imports and adding another blank line before the class would improve formatting.