Sample
pyint-ae8e6fbe197a-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.413 | 0–1; higher is more readable |
| Dorn | 0.806 | 0–1; higher is more readable |
| Mi | 0.514 | 0–1; higher is more readable |
| LLOC | 6 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.33 | 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.829 | −7.243 |
| 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.35 (log-odds).
Score = sigmoid(-0.35) = 0.413.
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 (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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.026 | +0.688 |
| 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 |
Intercept 0.07 + feature contributions = 1.423 (log-odds).
Score = sigmoid(1.423) = 0.806.
| Score | 0.514 |
|---|
| Score | 6 |
|---|
Run 1
The code is highly readable, clean, and well-structured. It clearly imports necessary modules and types at the top, defines a simple custom exception class with a descriptive name, and uses type-checking imports correctly. The class body is minimal and purposeful. There is no unnecessary nesting or verbosity, and each line serves a clear function. The only minor drawback is that the class 'HTTPError' and its base 'RequestException' lack inline comments or docstrings, which could slightly reduce immediate clarity for unfamiliar readers. Overall, the code is concise, logically organized, and easy to follow.
Run 2
The code is short and logically structured: imports are grouped (future, typing, third-party, local), and the class definition is trivial. Nesting is absent, intent is mostly clear (defines an HTTPError subclass of RequestException), and length is minimal. However, readability is limited by missing context—RequestException and CompatJSONDecodeError are not defined here, and the imported items other than BaseHTTPError are unused, which can confuse readers about purpose. Granularity is one action per line, and flow is natural. Score reflects good structure but slight ambiguity from extraneous imports.
Run 3
The code scores well for structure, clarity, and action granularity—it is flat, concise, and each import or class is on its own line. However, it lacks context: 'RequestException' is undefined (likely from an omitted import), the custom exception class is empty, and imported names like 'BaseHTTPError' and 'CompatJSONDecodeError' are unused. These gaps make the intent partially ambiguous and reduce reading flow.
Run 1
Code Structure: Imports followed by a single exception class provide simple, logical organization, although several imports appear unused. Nesting: No nested control flow; the class body is minimal. Clarity of intent: HTTPError clearly represents an exception, but RequestException is neither defined nor imported in the snippet, and the role of BaseHTTPError is unclear. Code length: Very concise, though unused imports add unnecessary clutter. Action granularity: Each import and statement occupies its own line. Reading flow: Straightforward top-to-bottom flow, slightly weakened by the unexplained dependencies and limited spacing between imports and the class.
Run 2
Code Structure: Imports precede a single exception class, giving the snippet a logical organization, though several imports appear unused. Nesting: No nested logic makes it easy to scan. Clarity of intent: HTTPError clearly represents an exception type, but RequestException is not defined or imported in the snippet, and the relationship to BaseHTTPError is unclear. Code length: Very concise, with minor clutter from unused imports. Action granularity: Each import and declaration occupies its own line. Reading flow: The flow from imports to class definition is natural, although additional spacing before the top-level class would improve visual separation.
Run 3
Code Structure: Imports followed by a simple exception class are logically organized, although RequestException is not defined or imported in the snippet. Nesting: Minimal, with only the class body indented. Clarity of intent: HTTPError clearly represents an exception, but its relationship to the imported BaseHTTPError is unclear, and all displayed imports are unused. Code length: Very concise, though unnecessary imports add noise. Action granularity: Each statement occupies its own line. Reading flow: Straightforward from imports to declaration, but missing blank-line separation between imports and the class and the unresolved base class slightly interrupt readability.