Sample
pyint-6467c1c2b2e7-I04
Replace names with deterministic minifier-style shortest identifiers
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. It has a clear, logical structure: importing necessary modules, defining a class with a docstring. Nesting is flat, with no nested blocks. The intent is clear—defining an HTTP error exception. The code is concise; it avoids unnecessary length by using `__future__` and `TYPE_CHECKING` for forward compatibility. Action granularity is appropriate; each import is on its own line, and the class definition is simple. Reading flow is natural, moving from imports to class definition. Minor deductions for the somewhat redundant `JSONDecodeError` alias and the unused `BaseHTTPError` import, which could confuse readers about their purpose.
Run 3
The code is highly readable due to its clear structure and purposeful imports. It logically organizes imports into standard library, third-party, and local modules. Nesting is minimal and flat. The class definition is concise and clearly named, extending a known base exception, with a descriptive docstring. Each line performs a single action, and the reading flow is natural. Minor deduction due to the slight ambiguity of aliasing imports and the incomplete context of 'RequestException', but overall it is clean and straightforward.
Run 1
Code Structure: Imports and the exception class are logically organized, though RequestException is not defined or imported in the snippet. Nesting: The code is flat, with only a simple class body. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but unused imports and the similarly named BaseHTTPError obscure the relationship between exception types. Code length: Very concise, although several imports appear unnecessary for the shown code. Action granularity: Each import and declaration occupies its own line. Reading flow: Natural top-to-bottom progression, with minor distractions from unused dependencies and insufficient spacing before the top-level class.
Run 2
Code Structure: Imports precede a clearly separated exception class, providing logical organization. Nesting: The code is flat apart from the class body. Clarity of intent: The class name and docstring clearly indicate an HTTP exception, though RequestException is not defined or imported in the snippet, and several imports are unused. Code length: The class is concise, but unused imports add clutter. Action granularity: Each statement occupies its own line. Reading flow: The import-to-class progression is natural, although an additional blank line before the top-level class would improve conventional formatting.
Run 3
Code Structure: Imports followed by an exception class provide a simple, logical organization, though several imports are unused in this snippet. Nesting: Only the class body is indented, making the code easy to scan. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but RequestException is not defined or imported in the shown code, leaving its origin unclear. Code length: Very concise, with some unnecessary import overhead. Action granularity: Each import and declaration occupies its own line. Reading flow: Natural top-to-bottom flow, although additional spacing between import groups and before the class would improve visual separation.