Sample
pyint-a5e74c6c4e4d-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.007 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 191 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.385 | 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. | 12976.356 | −428.22 |
| Source linesThe number of non-empty source lines. | 422 | +168.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.467 | −6.7 |
Intercept 8.87 + feature contributions = -257.25 (log-odds).
Score = sigmoid(-257.25) = 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. | 423 | −13.941 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 333 | +10.781 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 333 | −7.22 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 421.956 | +5.488 |
| 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.972 | −2.009 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.983 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.454 |
Intercept 0.07 + feature contributions = -5.019 (log-odds).
Score = sigmoid(-5.019) = 0.007.
| Score | 0.561 |
|---|
| Score | 191 |
|---|
Run 1
The code shows moderate readability with clear intent in method names and documentation, but suffers from several issues. The `prepare_body` method is overly long (60+ lines) and deeply nested with complex conditional logic, making it hard to follow. There are multiple concerns per method (URL validation, normalization, encoding all in `prepare_url`). The `prepare_auth` method has awkward type casting and an empty comment block that breaks flow. Some lines contain multiple operations (e.g., `host = idna.encode(host, uts46=True).decode('utf-8')`). Magic values like 'application/json' are scattered throughout. However, the code does have good documentation, consistent naming conventions, and logical organization of related functionality. The early returns in `prepare_url` help reduce nesting somewhat. Type hints are present but sometimes require `cast()` or `ignore` comments, signaling type system friction. Overall, it's maintainable but would benefit from extracting helper methods for body preparation and URL reconstruction.
Run 2
This code is highly readable, demonstrating excellent structure and clarity. It uses logical class organization, clear method names, and comprehensive docstrings with usage examples. Each method has a single responsibility, and the action granularity is appropriate—typically one operation per line. The nesting depth is generally reasonable, though `prepare_body` and `prepare_url` contain some deeper conditional blocks that are offset by clear comments and early returns. The imports are well-organized. The code flow is natural: methods are arranged in the order they are called, and inline comments effectively explain non-obvious operations like header validation and body position tracking. Minor issues include a stray blank line in `prepare_auth` and some long conditional lines, but these do not significantly impact readability. Overall, this is near-production-quality code with strong documentation and clear intent.
Run 3
The code is generally well-structured with clear class and method organization, but has several readability issues. The extensive import section is verbose and includes unused imports (datetime, SSLError, ProtocolError, etc.). Type annotations are present but complex, making signatures hard to scan. The `prepare_body` method is too long and handles multiple responsibilities (JSON encoding, stream detection, file uploads, content length), reducing clarity. Nesting is moderate but the `prepare_url` method contains many conditional branches and URL reconstruction logic that could be extracted. Some comments are helpful ('prepare_auth must be last') while others are outdated ('Python 2's json.dumps'). The `if length:` check incorrectly treats 0 as false, requiring readers to understand the implication. Action granularity is mostly good with one operation per line, but the flow jumps between concerns (parsing URL, validating parts, encoding params, rebuilding URL all in one method). Overall, the code is understandable to experienced Python developers but could benefit from method extraction and reduced typing complexity.
Run 1
Code Structure: Well organized into focused preparation methods, with a clear orchestration method; prepare_body handles noticeably more responsibilities. Nesting: Mostly shallow, but body serialization and stream handling introduce several nested branches. Clarity of intent: Descriptive method names, type annotations, docstrings, and explanatory comments make the purpose clear. Undefined dependencies in the excerpt, frequent type-ignore annotations, and an irrelevant comment add friction. Code length: Generally justified by HTTP edge cases, although lengthy comments, imports, and repetitive branching reduce concision. Action granularity: Nearly all lines perform a single action; the authentication call combined with a __dict__ update is less transparent. Reading flow: Preparation steps follow a natural sequence, and ordering constraints are documented. Long URL/body methods, dense inline annotations, and stray blank lines occasionally interrupt otherwise consistent flow.
Run 2
Code Structure: Well organized into focused preparation methods, with a clear orchestration method; the large import block and external mixin dependencies add overhead. Nesting: Mostly shallow, but prepare_body contains several nested branches that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, docstrings, and explanatory comments make HTTP preparation understandable; short names such as p and irrelevant or stale comments weaken clarity. Code length: Generally justified by protocol handling, though verbose comments, long type-ignore annotations, and some redundant branching reduce concision. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Preparation steps follow a natural sequence, and related behavior is grouped logically; lengthy body-processing logic, inconsistent whitespace, and comment clutter occasionally interrupt the flow.
Run 3
Code Structure: Well organized into focused preparation methods, with a clear orchestration method separating concerns. Nesting: Mostly shallow, although prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, docstrings, and explanatory comments make HTTP preparation behavior understandable; abbreviated variables, type-ignore clutter, and a few irrelevant or outdated comments reduce clarity. Code length: Generally justified by protocol edge cases, but prepare_url and prepare_body are lengthy and could benefit from helper extraction. Action granularity: Statements generally perform one action per line, with only a few dense expressions such as authentication state updates. Reading flow: Preparation steps follow a natural sequence, and ordering constraints are documented. However, extensive imports, long annotation comments, inconsistent blank spacing, and dependencies not defined in the snippet occasionally interrupt the flow.