Sample
pyint-631f41ed3abf-I02
Shorten method, parameter, and local names without collisions
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 | 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 with a clear, single-purpose class definition and appropriate use of type-checking imports. Structure is logical: imports followed by a concise exception subclass with a clear docstring. Nesting is minimal, intent is unambiguous, and length is appropriate for the task. Action granularity is fine—each line conveys one concept. Reading flow is natural, from imports to class definition. Minor deductions: 'RequestException' is not imported in the shown snippet, which could confuse readers about its origin, and the unused imports (TYPE_CHECKING, Any, BaseHTTPError, CompatJSONDecodeError) raise slight ambiguity about their purpose without additional context.
Run 3
The code is concise and follows a clear logical structure: future import, typing imports, third-party import, local import, then a class definition. Nesting is nonexistent, and intent is evident from the docstring. The action granularity is one import or definition per line, and the reading flow is natural. The score is slightly reduced because the class body is empty apart from a docstring, and the `TYPE_CHECKING`/`Any` imports are unused in this snippet, which could confuse readers about their purpose.
Run 1
Code Structure: Imports precede a focused exception class, giving clear organization, though RequestException is not defined or imported in the snippet. Nesting: No nested logic; the class contains only a docstring. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but unused imports and aliases add unexplained context. Code length: Very concise, with some apparently unnecessary imports. Action granularity: Each import and declaration occupies its own line. Reading flow: Straightforward top-to-bottom progression; additional spacing between import groups and before the class would improve visual separation.
Run 2
Code Structure: Imports precede a clearly separated exception class, providing logical organization. Nesting: No nested control flow; the class contains only a docstring. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but RequestException is not defined or imported in the snippet, and several imports are unused. Code length: Very concise, although unused imports add clutter. Action granularity: Each import and declaration occupies its own line. Reading flow: Straightforward top-to-bottom flow, with minor spacing shortcomings between imports and the top-level class.
Run 3
Code Structure: Imports followed by a single exception class are logically organized, though RequestException is not defined or imported in the snippet and several imports appear unused. Nesting: No unnecessary nesting. Clarity of intent: The descriptive class name and brief docstring clearly identify an HTTP exception, but the missing base-class context reduces clarity. Code length: Very concise, with no redundant implementation. Action granularity: Each import and declaration occupies its own line. Reading flow: Straightforward top-to-bottom flow; clearer import grouping and standard spacing before the class would improve readability.