Sample
pyint-e42523adfb4f-I13
Lower every eligible synchronous for loop to a while loop
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 | 196 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.387 | 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. | 13313.165 | −439.334 |
| 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.697 |
Intercept 8.87 + feature contributions = -266.361 (log-odds).
Score = sigmoid(-266.361) = 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. | 338 | −7.335 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 426.963 | +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.958 | −2.009 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.986 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.451 |
Intercept 0.07 + feature contributions = -5.071 (log-odds).
Score = sigmoid(-5.071) = 0.006.
| Score | 0.561 |
|---|
| Score | 196 |
|---|
Run 1
The code scores 15/20. Structure is logical with clear class organization and well-documented methods, but `prepare_body` and `prepare_url` contain complex conditional blocks. Nesting reaches 3-4 levels in spots, particularly in `prepare_body`'s iterable checks and `prepare_cookies`' type checks, though most early returns help flatten flow. Intent is generally clear from comprehensive docstrings and inline comments explaining OAuth ordering constraints. Length is reasonable for a 400-line request preparation class, though type casting comments clutter several lines. Action granularity is mostly one-action-per-line but breaks down with complex conditionals like `if is_iterable and not isinstance(...)`. Reading flow follows a natural progression (method → URL → headers → body → auth → cookies → hooks), but awkward constructs like `__import__('builtins').iter()` in `prepare_hooks` break idiomatic Python readability.
Run 2
The code is generally readable with good structure, but has some issues. It's well-organized with clear method separation and good docstrings, but the massive import block at the top is verbose. Nesting is mostly flat, though prepare_body() has multiple levels. Intent is clear with descriptive method names, but some comments are overly verbose or unnecessary. Code length is reasonable per method but could be more concise in places. Action granularity is mostly one-action-per-line, though some lines are overly long (e.g., the type ignores). Reading flow is natural in most methods, but prepare_hooks() uses an awkward __import__ pattern for iteration that breaks flow, and prepare_url() is quite dense. The code is professional but not exceptional.
Run 3
The code shows good structure with clear class organization and type hints, but has readability issues. The imports section is very long, though logically grouped. Nesting is moderate with some deep conditionals in `prepare_body`. Most methods have clear intent with descriptive names and docstrings. Code length is reasonable for functionality, but `prepare_body` is lengthy. Action granularity is mostly good, though some lines combine multiple operations. The main concern is `prepare_hooks` which uses unconventional `__import__('builtins')` calls instead of standard Python iteration, breaking reading flow. Comments are helpful when present. Type annotations are extensive but sometimes require casting which adds noise. Overall, the code is maintainable for experienced Python developers but has sections that could be refactored for clarity.
Run 1
Code Structure: Well separated into focused preparation methods, with a clear orchestration method. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, annotations, and docstrings explain most behavior; vague comments and extensive type-ignore annotations add noise. Code length: Generally justified by HTTP edge cases, though verbose imports, comments, and the manual iterator loop could be simplified. Action granularity: Statements generally perform one action per line, making changes easy to follow. Reading flow: The preparation sequence is natural and ordering constraints are documented. However, prepare_hooks disrupts readability with repeated dynamic builtins imports and a while/try loop instead of a straightforward for loop. Overall, readable and organized, with localized complexity and unnecessary verbosity.
Run 2
Code Structure: Request preparation is logically divided into focused methods, although prepare_body combines several responsibilities. Nesting: Most methods are relatively flat, but body handling contains multiple nested conditionals and exception handlers. Clarity of intent: Descriptive method names, annotations, and docstrings explain the purpose well; cryptic variables, an irrelevant comment, and numerous type-ignore annotations add noise. Code length: Much of the length supports legitimate HTTP edge cases, but verbose comments and the expanded hook iteration are unnecessarily long. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The main prepare method presents a clear sequence, with helpful explanations of ordering constraints. However, prepare_hooks abruptly replaces straightforward iteration with dynamic builtins imports and manual StopIteration handling, disrupting otherwise conventional Python flow.
Run 3
Code Structure: Preparation responsibilities are logically separated into focused methods, although prepare_body combines several complex paths. Nesting: Most methods are shallow, but body handling contains multiple nested conditionals and exception blocks. Clarity of intent: Descriptive method names, annotations, and documentation explain the request lifecycle; obscure comments, terse variables, and type-ignore clutter reduce clarity. Code length: Generally justified by protocol edge cases, but verbose comments and the manually expanded iterator loop add unnecessary length. Action granularity: Statements mostly perform one action per line, making state changes easy to track. Reading flow: prepare provides a clear sequence, and individual methods mostly follow natural validation-to-transformation order. However, prepare_hooks disrupts this flow with repeated dynamic builtins imports and a while/try/except loop instead of a straightforward for loop. Overall, readable and well organized, with localized complexity and avoidable verbosity.