Sample
pyint-29f0869fa7d9-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.07 | 0–1; higher is more readable |
| Mi | 0.616 | 0–1; higher is more readable |
| LLOC | 134 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs |
| BTTF | 0.462 | 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. | 8986.266 | −296.547 |
| Source linesThe number of non-empty source lines. | 314 | +125.6 |
| 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.413 | −6.619 |
Intercept 8.87 + feature contributions = -168.696 (log-odds).
Score = sigmoid(-168.696) = 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. | 315 | −10.117 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 246 | +7.772 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 246 | −5.224 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 313.872 | +3.978 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 92.959 | +0.695 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.044 | +0.513 |
| 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. | 92.984 | −0.273 |
Intercept 0.07 + feature contributions = -2.586 (log-odds).
Score = sigmoid(-2.586) = 0.07.
| Score | 0.616 |
|---|
| Score | 134 |
|---|
Run 1
The code is well-structured and maintains good readability despite its complexity. The module follows a logical organization with clear imports and class separation. Nesting depth is generally controlled, with the main resolve_redirects method using sequential if-statements rather than deeply nested conditionals. Clear type hints and descriptive variable names enhance intent, though some implicit behaviors (e.g., accessing resp.content to consume the socket) could benefit from helper methods. Action granularity is mostly one action per line, with occasional multi-step operations grouped logically. Reading flow is natural for a redirect-handling utility, with comments providing context for non-obvious decisions. Minor drawbacks include the long resolve_redirects method (~90 lines) and some reliance on internal knowledge like _body_position. Overall, the code maintains requests library's characteristic clarity, with excellent docstrings and deliberate comment placement explaining edge cases.
Run 2
The code is well-structured with clear separation of concerns across methods, each handling a specific redirect-related responsibility. Imports are organized and type hints improve clarity. The `resolve_redirects` method is somewhat long with multiple responsibilities (history tracking, URL normalization, method rebuilding, cookie handling, proxy/auth rebuilding), which slightly reduces readability due to the volume of inline logic. Nesting is generally shallow except for a few conditional blocks. Comments effectively explain non-obvious behavior (e.g., RFC references, browser quirks). Action granularity is mostly one action per line, aiding scanning. However, some sections, like the conditional header purging and the `rewindable` calculation, are dense and could benefit from helper methods for cleaner flow. Overall, readable and maintainable with only minor complexity concerns.
Run 3
The code is moderately readable but suffers from a very long and deeply nested `resolve_redirects` method. The mixin structure is logical, and individual methods like `should_strip_auth` and `rebuild_method` are clear. However, the main redirect loop mixes many concerns: consuming the socket, updating history, handling URL fragments, managing cookies, and re-sending requests, all within a single method. This creates high complexity and reduces scanability. Helpful comments explain *why* certain non-obvious decisions are made, which aids intent. Action granularity is generally one action per line, but some sections are dense. Reading flow is natural in smaller methods but breaks down in the large loop. Overall, it’s above average due to type hints and comments, but falls short of high readability because the central logic is monolithic.
Run 1
Code Structure: Related redirect behavior is organized into a cohesive mixin with focused helper methods, although resolve_redirects combines many responsibilities. Nesting: Mostly shallow conditionals and early returns; the redirect loop adds moderate nesting without becoming difficult to follow. Clarity of intent: Descriptive method names, type annotations, docstrings, and protocol-specific comments explain most decisions. Unshown type references and the generator annotation conflicting with its optional request yields introduce minor ambiguity. Code length: Most helpers are concise, but resolve_redirects is lengthy and some comments are verbose. Action granularity: Statements generally perform one action per line, with clear separation between preparation, cleanup, authentication, and sending. Reading flow: The redirect lifecycle follows a natural sequence, supported by whitespace and explanatory comments; mutations across req, prepared_request, resp, and url require careful tracking.
Run 2
Code Structure: Responsibilities are logically separated into redirect, authentication, proxy, and method helpers, although resolve_redirects combines many stages. Nesting: Mostly shallow conditionals and early returns; the main redirect loop introduces moderate nesting without becoming tangled. Clarity of intent: Descriptive method names, type annotations, docstrings, and protocol-specific comments explain behavior well. Abbreviations such as resp, req, and hist, plus unexplained _t annotations, slightly reduce clarity. Code length: Most helpers are concise, but resolve_redirects is lengthy and could benefit from additional extraction; some comments are verbose. Action granularity: Statements generally perform one action per line, with clear intermediate variables. Reading flow: Processing proceeds naturally from response cleanup through URL normalization, request rebuilding, and sending. Blank lines and comments distinguish phases, though the long central method and mixed response/request yielding require careful reading.
Run 3
Code Structure: Well-organized mixin with focused helper methods, though resolve_redirects combines many responsibilities. Nesting: Mostly shallow conditionals and early returns; the redirect loop adds moderate nesting without becoming tangled. Clarity of intent: Descriptive method names, type annotations, docstrings, and protocol-specific comments explain behavior well. Abbreviations such as resp, req, and hist, unresolved type references such as _t, and the generator's mismatched return annotation introduce ambiguity. Code length: Most helpers are concise, but resolve_redirects is lengthy and could benefit from extracting URL normalization and request preparation. Action granularity: Statements generally perform one action per line, with readable multiline expressions and calls. Reading flow: Redirect processing follows a logical sequence, supported by useful comments, although numerous edge cases, verbose commentary, and apparently unused imports add visual noise.