Sample
pyint-cb46e2424dd7-I09
Select one of ten low-readability unrelated code templates per class
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 | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 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 and well-structured. It begins with standard future/typing imports, then third-party and local imports, following PEP 8 conventions. The class definition is concise with clear multiple inheritance and a descriptive docstring explaining when the error occurs and that requests are safe to retry. Nesting is minimal (flat), intent is clear, and action granularity is appropriate. The only minor issue is the unused imports (TYPE_CHECKING, Any, BaseHTTPError, CompatJSONDecodeError), which slightly reduce clarity and could confuse readers about intent. Overall readability is high.
Run 3
The code is clean and well-structured. It uses clear imports, a logical class hierarchy, and a concise docstring that explains both the error and retry behavior. Naming is explicit and intent is clear. The only minor deductions are for limited context (relying on external definitions) and the slightly verbose dual inheritance, but overall readability is high.
Run 1
Code Structure: Imports followed by a focused exception class provide clear organization. Nesting: The code is flat, with only the class body. Clarity of intent: The 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: Concise, but the visible imports are unused. Action granularity: Each import and declaration occupies its own line. Reading flow: Natural top-to-bottom flow, although an additional blank line before the class would improve standard Python formatting.
Run 2
Code Structure: The imports followed by a single exception class form a straightforward, logical structure. Nesting: There is no unnecessary nesting. Clarity of intent: The class name and docstring clearly explain the connection timeout and retry safety, though ConnectionError and Timeout are not defined or imported in the snippet, and several imports are unused. Code length: The code is concise, with some avoidable import clutter. Action granularity: Each import and declaration occupies its own line, making individual elements easy to scan. Reading flow: The flow from imports to class declaration to documentation is natural, although an additional blank line before the top-level class would improve conventional Python formatting.
Run 3
Code Structure: Imports followed by a focused exception class provide logical organization, though several imports appear unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name and docstring clearly describe a connection timeout and its retry safety; however, ConnectionError and Timeout are not defined or imported here, leaving their origins unclear. Code length: Concise, with no unnecessary implementation. Action granularity: Each import and declaration occupies its own line, avoiding compressed actions. Reading flow: Natural progression from dependencies to the exception definition, although an additional blank line before the top-level class would improve conventional formatting.