Sample
pyint-59427968d4b8-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.65 | 0–1; higher is more readable |
| Dorn | 0.86 | 0–1; higher is more readable |
| Mi | 0.307 | 0–1; higher is more readable |
| LLOC | 6 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.789 | 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.692 | −7.039 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 157.891 | −5.21 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = 0.621 (log-odds).
Score = sigmoid(0.621) = 0.65.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.019 | +0.761 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| 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. | 74 | +0.531 |
| 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. | 9.88 | −0.272 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 60.636 | +0.174 |
Intercept 0.07 + feature contributions = 1.813 (log-odds).
Score = sigmoid(1.813) = 0.86.
| Score | 0.307 |
|---|
| Score | 6 |
|---|
Run 1
The code is highly readable and well-structured. It uses clear imports with future annotations for modern type hinting. The exception class `ConnectTimeout` inherits logically from `ConnectionError` and `Timeout`, accurately reflecting its purpose. The docstring concisely explains when the error occurs and explicitly notes that retrying is safe, which is crucial for error handling. Nesting is nonexistent, and each import is on its own line, following clean action granularity. The code length is minimal and avoids unnecessary complexity. Reading flow is natural: imports first, then class definition with documentation. Minor deductions only because the docstring could include a period after the first sentence, and the class body contains only a docstring, which is acceptable for an exception class.
Run 2
The code is clean, well-structured, and readable. It has a flat structure with clear imports and a single class definition that combines multiple exception types logically. The docstring clearly explains the error's meaning and retry safety, showing good intent. The code is concise with no unnecessary length, and each line performs a distinct action. Reading flow is natural, following standard Python conventions. Minor improvements could include more explicit type annotations or additional context, but overall this is highly readable.
Run 3
The code is a simple class definition with an import block and a docstring, so it is not deeply nested or excessively long. However, readability suffers from ambiguity: the imported 'Timeout' is never shown or imported in this snippet, making the inheritance unclear. Additionally, several imports (BaseHTTPError, CompatJSONDecodeError) appear unused here, which raises questions about intent. The class itself is clear and concise, with a helpful docstring, but the overall structure feels incomplete. Action granularity and reading flow are fine, but the missing context and unused imports make the code harder to evaluate as a standalone unit.
Run 1
Code Structure: Imports followed by a single exception class provide a simple, logical organization. Nesting: There is no complex nesting. Clarity of intent: The descriptive class name and docstring clearly explain the connection timeout and retry safety, although ConnectionError and Timeout are not defined or imported in the snippet. Code length: The code is concise, but several imports appear unused. Action granularity: Each import and the class declaration occupies its own line. Reading flow: The progression from imports to the class and its documentation is natural and easy to follow.
Run 2
Code Structure: Imports precede a clearly defined exception class, giving the snippet a logical organization. Nesting: There is no unnecessary nesting. Clarity of intent: The descriptive class name and docstring clearly explain the timeout condition and retry safety, though ConnectionError and Timeout are not defined or imported in the snippet. Code length: The class is concise, but several imports appear unused in the provided code. Action granularity: Each import and declaration occupies its own line, with no crowded operations. Reading flow: The progression from imports to class definition to documentation is natural; an additional blank line before the top-level class would improve formatting.
Run 3
Code Structure: Imports followed by a single exception class provide straightforward organization. Nesting: Only the class body is indented, with no nested control flow. Clarity of intent: The class name and docstring clearly describe a connection timeout and retry safety, although ConnectionError and Timeout are not defined or imported in the snippet. Code length: Very concise, but several imports appear unused in the shown code. Action granularity: Each import and declaration occupies its own line. Reading flow: Natural top-to-bottom progression; an additional blank line before the top-level class would improve conventional Python formatting.