Sample
pyint-cb5bcf6d3ffa-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.132 | 0–1; higher is more readable |
| Mi | 0.336 | 0–1; higher is more readable |
| LLOC | 96 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.25 | 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. | 6667.363 | −220.023 |
| Source linesThe number of non-empty source lines. | 179 | +71.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.258 | −6.387 |
Intercept 8.87 + feature contributions = -145.94 (log-odds).
Score = sigmoid(-145.94) = 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. | 180 | −5.337 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 162 | +4.866 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 162 | −3.297 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 178.917 | +2.091 |
| 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. | 130.939 | −1.881 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 130.989 | +1.309 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.066 | +0.298 |
Intercept 0.07 + feature contributions = -1.88 (log-odds).
Score = sigmoid(-1.88) = 0.132.
| Score | 0.336 |
|---|
| Score | 96 |
|---|
Run 1
The code has clear structure overall (class, properties, methods), but readability is hampered by inconsistent import formatting, excessive vertical spacing in imports, and some awkward line breaks (e.g., `__iter__` splitting). Nested logic in `_encode_params` and `_encode_files` creates moderate depth, though each action is reasonably granular. Intent is mostly clear, but long type annotations and overloads add noise. The `_encode_files` method is quite long (40+ lines) and handles multiple concerns, reducing scanability. The inconsistent alignment of imports and overly spacious line breaks disrupt reading flow. Some comments are helpful, but the code density and formatting inconsistencies prevent higher readability.
Run 2
The code has serious readability problems stemming primarily from formatting, not logic. Inconsistent alignment and spacing in imports (e.g., multiple spaces between names, trailing commas placed oddly) create visual noise. Functions like _encode_files contain deeply nested conditionals (especially the tuple-length handling inside a for loop) and multiple actions crammed onto single lines or awkward line breaks, reducing clarity. The `path_url` property is relatively clear, but `_encode_params` mixes type checking, iteration, and encoding logic with an `if/elif/else` chain containing nested loops. Line lengths and broken indentation (e.g., in `_encode_files` signature and tuple construction) hurt the reading flow. While the code's purpose—encoding parameters and files for requests—is understandable from names and docstrings, the actual implementation requires slow, effortful parsing due to poor structural organization and inconsistent formatting. It violates several criteria: action granularity is poor, nesting is deep, and the import section is disorganized.
Run 3
The code has some readable elements like descriptive method names and docstrings, but overall readability is poor. Imports are inconsistently formatted with odd spacing. Multiple function overloads add complexity but are logically organized. However, the main methods contain deeply nested conditionals, especially _encode_files with its tuple-unpacking logic. The _encode_params method mixes type checking with data transformation, making intent unclear. Line lengths are inconsistent with some very long multi-purpose lines. The multipart tuple handling (2-tuple, 3-tuple, 4-tuple) lacks explanatory comments and has ambiguous variable names like 'ft' and 'fh'. The reading flow is disrupted by excessive vertical spacing in some imports and cramped code in methods. While not the worst code, it falls below average readability standards.
Run 1
Code Structure: Responsibilities are logically grouped within an encoding mixin, with separate methods for URL paths, parameters, and multipart files. Nesting: Parameter and file encoding contain several nested loops and conditionals, increasing cognitive load. Clarity of intent: Method names, docstrings, and type annotations explain the purpose well, but abbreviated variables such as k, vs, fn, fp, ft, and fh obscure details. Code length: Mostly justified by supported input variants, though overloads and extensive imports add visual bulk. Action granularity: Most lines perform a single action; tuple unpacking and inline conditional expressions remain reasonably understandable. Reading flow: Processing generally follows a natural validation-to-transformation sequence, but inconsistent spacing, awkward import formatting, and malformed-looking line wrapping interrupt scanning. Overall, the code is understandable but would benefit from consistent formatting, descriptive local names, and reduced nesting.
Run 2
Code Structure: Related encoding operations are logically grouped in a mixin with separate methods, although the extensive import block adds clutter. Nesting: Parameter and multipart encoding contain several nested loops and conditionals, making some paths harder to follow. Clarity of intent: Descriptive method names, docstrings, and type annotations explain the purpose well; abbreviated variables such as k, vs, fn, fp, ft, and fh weaken local clarity. Code length: Mostly justified by supported input formats, but repeated normalization logic and overload declarations increase reading effort. Action granularity: Generally one operation per line, with tuple unpacking and conditional expressions remaining manageable. Reading flow: Processing follows a natural sequence from validation through normalization to encoding, but inconsistent whitespace, awkward line wrapping, and crowded imports interrupt scanning.
Run 3
Code Structure: Related URL and request-encoding operations are logically grouped in a mixin with separate methods, although imports are visually cluttered. Nesting: Encoding methods contain several nested loops and conditionals, especially multipart field handling, increasing reading effort. Clarity of intent: Method names, docstrings, type annotations, and comments explain purpose well; abbreviated variables such as k, vs, fn, fp, ft, and fh obscure details. Code length: Mostly justified by supported input formats, but overload declarations and repeated normalization logic add visual bulk. Action granularity: Most statements perform one action per line; tuple unpacking and conditional expressions remain manageable, though malformed spacing makes some expressions difficult to scan. Reading flow: Processing generally follows a natural sequence from validation through normalization to encoding, but inconsistent import formatting, excessive inline whitespace, and uneven spacing between declarations interrupt the flow.