Sample
pyint-7b3a1720d798-I10
Deterministically remove some optional blank lines and bracketed line breaks
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.001 | 0–1; higher is more readable |
| Mi | 0.416 | 0–1; higher is more readable |
| LLOC | 192 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.269 | 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. | 12993.171 | −428.775 |
| Source linesThe number of non-empty source lines. | 368 | +147.2 |
| 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.457 | −6.686 |
Intercept 8.87 + feature contributions = -279.39 (log-odds).
Score = sigmoid(-279.39) = 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. | 368 | −11.993 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 280 | +8.948 |
| 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. | 238.989 | −6.458 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 279 | −5.981 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 367.929 | +4.733 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 238.992 | +3.052 |
| 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 = -7.173 (log-odds).
Score = sigmoid(-7.173) = 0.001.
| Score | 0.416 |
|---|
| Score | 192 |
|---|
Run 1
The code has severe readability issues. The import section has several multi-import lines with erratic spacing and alignment attempts, making it visually cluttered. Function signatures like prepare() and prepare_url() are broken into multiple lines with inconsistent indentation. The critical issue is inconsistent vertical spacing—some methods are separated by blank lines while others are adjacent (e.g., __repr__/copy, prepare_url/prepare_headers). Several lines contain multiple statements or actions (e.g., body assignment, content-type assignment). The method definitions have parameters aligned oddly, with some having multiple parameters on one line and others spread vertically. Comments are sparse and don't adequately explain complex logic. The type annotations are clear, which helps, but aren't enough to offset the formatting problems. The code structure itself is logical (each preparation method has a clear purpose), but the visual presentation destroys readability. The deep indentation in prepare_body's conditional logic also hurts comprehension.
Run 2
The code has a solid logical structure with clear class and method organization, but suffers from severe formatting inconsistencies that significantly impair readability. The import section contains erratic spacing and line breaks, with some imports crammed together and others spread oddly. Function signatures like prepare() and prepare_url() have parameters on the same line with excessive spacing, while other methods like prepare_auth() use inconsistent indentation. Some conditional blocks mix operations per line, violating the one-action-per-line principle. The nesting level is generally acceptable, and method docstrings help clarify intent, but the wildly inconsistent spacing, alignment, and line breaks force readers to constantly adjust visual parsing. While the underlying code follows reasonable logical flow from preparation methods to final request assembly, the formatting chaos suggests automated merging or lazy formatting tools, making this code difficult to maintain or review. The code is technically correct but visually jarring, requiring significant cleanup to achieve professional readability standards.
Run 3
The code has clear docstrings and logical sections, but suffers from inconsistent formatting that harms readability. Import statements contain odd spacing and alignment issues (e.g., multiple items on one line, irregular indentation), making them visually noisy. Function signatures like `prepare()` cram multiple parameters onto single lines with excessive whitespace, while `prepare_url()` spreads parameters across three lines unnecessarily. Method definitions occasionally lack blank lines between them (e.g., `prepare_method` followed immediately by `_get_idna_encoded_host`). Some lines exceed reasonable length, and there's inconsistent vertical spacing throughout. The logic itself is reasonably well-organized with good comments explaining non-obvious behavior, but the formatting inconsistencies force readers to work harder than necessary. Action granularity is generally acceptable—most lines perform one action—though several conditionals and function calls are awkwardly split. Overall, the code is comprehensible but would benefit from consistent black-style formatting and more careful line-break decisions.
Run 1
Code Structure: Well-organized into focused preparation methods, with a central method coordinating request construction. Nesting: Mostly moderate, but 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 communicate purpose well; an irrelevant comment and numerous type-ignore annotations add noise. Code length: Generally justified by HTTP edge cases, though lengthy methods and verbose comments reduce concision. Action granularity: Executable statements usually perform one action per line, but crowded imports and parameter declarations hinder scanning. Reading flow: Preparation follows a logical sequence, and ordering constraints are documented. However, inconsistent whitespace, unusually long lines, and missing blank lines between some methods disrupt the otherwise natural flow.
Run 2
Code Structure: Request preparation is logically divided into focused methods, although prepare_body handles several distinct cases. Nesting: Most methods are relatively flat, but body preparation includes multiple nested conditionals and exception handlers. Clarity of intent: Descriptive method names, type annotations, and explanatory docstrings make the purpose clear; cryptic comments and references to definitions absent from the snippet add friction. Code length: Length is mostly justified by HTTP edge cases, though some comments are verbose or outdated and complex branches could be extracted. Action granularity: Executable statements generally perform one action per line, but crowded imports and parameter declarations impair scanning. Reading flow: The preparation sequence is natural and ordering constraints are documented, but inconsistent spacing, long lines, and missing blank lines between methods noticeably disrupt readability.
Run 3
Code Structure: Well-organized into focused preparation methods, with a clear orchestration method separating concerns. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, and explanatory docstrings make the purpose clear; cryptic temporary names, noisy type-ignore comments, and an irrelevant comment weaken clarity. Code length: Generally justified by HTTP edge cases, although lengthy comments and the large prepare_body method could be streamlined. Action granularity: Executable statements generally perform one action per line, but imports and parameter declarations are awkwardly packed together. Reading flow: Preparation follows a natural sequence, yet inconsistent spacing, excessively long lines, and missing blank lines between methods disrupt scanning. Overall, the underlying design is readable, but formatting and localized complexity noticeably reduce accessibility.