Sample
pyint-6da15825e41e-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.006 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 197 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.67 | 0–20; mean of three runs |
| BTTF | 0.356 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 13215.472 | −436.111 |
| Source linesThe number of non-empty source lines. | 427 | +170.8 |
| 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.464 | −6.696 |
Intercept 8.87 + feature contributions = -263.137 (log-odds).
Score = sigmoid(-263.137) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 428 | −14.118 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 338 | +10.954 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 337 | −7.312 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 426.956 | +5.558 |
| 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. | 133.967 | −2.009 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.984 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.457 |
Intercept 0.07 + feature contributions = -5.043 (log-odds).
Score = sigmoid(-5.043) = 0.006.
| Score | 0.561 |
|---|
| Score | 197 |
|---|
Run 1
The code demonstrates strong readability through clear organization, flat structure despite complex logic, and explicit type annotations. Logical grouping of related functions (prepare_method, prepare_url, etc.) and consistent naming conventions enhance comprehension. Each operation is effectively one action per line, and comments explain non-obvious rationale (e.g., IDNA handling, auth ordering, cookie behavior). Some mild complexity appears in `prepare_url` URL reconstruction and `prepare_body` branching, but these remain navigable due to focused single-responsibility methods. A minor blemish is the dead code for `travel_distance` in `__init__`, which adds no value. Overall, the code is highly readable for a library-level implementation with intricate protocol requirements.
Run 2
The code is generally structured well with clear method separation and consistent typing, but readability is reduced by several issues. The imports section is excessively long and disorganized, making it hard to quickly understand dependencies. There are unexplained inconsistencies like dead code (unused `starting_position`, `ending_position`, `travel_distance` variables in `__init__`), suspicious comments ('Nottin' on you.'), and ineffective type checking (isinstance checks with duplicate str/bytes). Nesting is mostly controlled but some methods like `prepare_body` have complex conditional logic with multiple branches. The code length is reasonable for functionality but could be more concise. Action granularity is generally good with one action per line. Reading flow is interrupted by scattered comments that sometimes obscure rather than clarify. The class has a clear purpose but several implementation details feel tangled, particularly around auth handling and body preparation where the logic jumps between different concerns. Overall, it's maintainable code but requires careful reading to understand all edge cases.
Run 3
The code is moderately readable with clear method separation and descriptive names. However, it includes irrelevant variable declarations (starting_position, ending_position, travel_distance) that add no value and suggest copy-pasted code. The prepare_url method is overly long with many comments and steps, making it harder to follow at a glance. Nesting is mostly shallow but increases inside prepare_body, especially with multiple conditional paths and inline comments. Action granularity is generally good—most lines perform one logical operation—but some blocks mix validation, assignment, and transformation in dense clusters. The type annotations improve clarity, though the heavy use of Union types and cast() calls adds noise. Reading flow is natural for a library implementing a class with sequential preparation steps, but could benefit from extracting URL parsing and body encoding into smaller helper methods to reduce cognitive load.
Run 1
Code Structure: Well-organized class with focused preparation methods and a clear orchestration method, though unrelated travel-distance calculations in __init__ disrupt cohesion. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that require careful tracking. Clarity of intent: Descriptive method names, type annotations, docstrings, and ordering comments explain most behavior; vague names such as p and r, irrelevant comments, and frequent type-ignore annotations add noise. Code length: Generally justified by HTTP preparation complexity, but the extensive import block, some verbose comments, unused calculations, and long methods reduce concision. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The sequential prepare calls and consistent formatting provide a natural progression, although streaming/body branches, lengthy inline annotations, and unrelated initialization logic interrupt it.
Run 2
Code Structure: Well-organized class with focused preparation methods and a clear orchestration method, though prepare_body combines several responsibilities. Nesting: Mostly shallow, but multipart and streaming branches introduce deeper nesting. Clarity of intent: Descriptive names, type annotations, and docstrings explain HTTP preparation well; unrelated travel-distance calculations, an irrelevant comment, and missing definitions in the excerpt create distractions. Code length: Generally justified by protocol handling, but lengthy comments, unused imports in this excerpt, and redundant branching add bulk. Action granularity: Consistently uses one action per line, with only a few dense expressions and long type-ignore comments. Reading flow: Preparation stages follow a natural sequence, and comments explain ordering constraints; the large import block and complex body-handling logic occasionally interrupt the flow.
Run 3
Code Structure: Well organized into focused preparation methods, with a clear orchestration method; body handling could be split further. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive names, type annotations, and useful docstrings explain most behavior. However, unrelated travel-distance calculations in __init__ and the 'Nottin’ on you' comment distract from intent. Code length: Generally justified by HTTP edge cases, though lengthy imports, verbose type-ignore comments, and some redundant branching add clutter. Action granularity: Consistently uses one action per line, making state changes easy to follow. Reading flow: Preparation proceeds naturally from method and URL through headers, cookies, body, authentication, and hooks, with comments explaining ordering constraints. Long expressions and complex body-processing paths occasionally interrupt this otherwise clear flow.