Sample
pyint-0b39cd0f771e-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.213 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 96 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs |
| BTTF | 0.262 | 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. | 214 | +85.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.278 | −6.417 |
Intercept 8.87 + feature contributions = -131.97 (log-odds).
Score = sigmoid(-131.97) = 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. | 215 | −6.576 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 197 | +6.077 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 197 | −4.1 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 213.918 | +2.58 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.94 | +0.743 |
| 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. | 95.967 | −0.4 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.067 | +0.296 |
Intercept 0.07 + feature contributions = -1.309 (log-odds).
Score = sigmoid(-1.309) = 0.213.
| Score | 0.561 |
|---|
| Score | 96 |
|---|
Run 1
The code shows a mix of strong and weak readability elements. Structure is logical with clear class and method separation, but the import section is excessively long and includes numerous aliased or duplicate imports, making it feel cluttered. Nesting is moderate—acceptable for data transformation logic, though loops within loops reduce flatness. Intent is generally clear: encoding parameters and files for requests, with helpful docstrings. However, the `_encode_files` method grows long and handles many edge cases, slightly obscuring its purpose. Code length is verbose, particularly with type overloads and multiple conditional branches; some lines are dense but reasonable. Action granularity is mostly one action per line, but tuple unpacking and conditional assignments pack multiple steps. Reading flow is natural for experienced Python developers but disrupted by the massive import block and dense internals. The type hints and modern Python features improve clarity, yet the overall complexity prevents higher readability.
Run 2
The code is generally well-structured with clear sectioning, type hints, and docstrings, but it suffers from several readability issues. The imports are extensive and aliased, making it hard to track dependencies. The `_encode_files` method has deep nesting (up to 4 levels) and multiple conditional branches, which obscures the flow. Action granularity is mixed—some lines do multiple things (e.g., tuple unpacking with conditional logic). The `_encode_params` method is clearer but still has nested loops and inline encoding. The use of overloads and type aliases helps clarity but adds cognitive overhead. Path_url is flat and readable. Overall, the code maintains reasonable consistency but could benefit from extracting helper methods and reducing nesting to improve readability.
Run 3
The code exhibits good structure and organization with clear sections, type hints, and overloads, but suffers from complexity in certain areas. The path_url property is clean and readable. _encode_params has moderate nesting but reasonable clarity. _encode_files is the weakest section: it contains deeply nested loops, multiple conditionals, and mixed responsibilities (validation, field processing, file tuple unpacking, RequestField creation). The tuple length checks (0x2, 0x3) are unclear and reduce readability. The action granularity is mostly good, but some lines combine multiple operations like conditional encoding. The code is generally well-commented but lacks consistent style in some areas. Overall, it's maintainable code with clear intent, but the multipart encoding function could benefit from decomposition into smaller, more focused functions to improve readability.
Run 1
Code Structure: Logically grouped imports and a cohesive mixin separate URL construction, parameter encoding, and multipart encoding. Nesting: Encoding routines contain several nested loops and conditionals, making individual paths harder to follow. Clarity of intent: Descriptive method names, docstrings, and type annotations explain purpose well, but abbreviated variables such as k, vs, fn, fp, ft, and fh obscure details; hexadecimal tuple lengths are unnecessarily cryptic. Code length: Generally proportionate to the supported input formats, although overloads and repetitive conversion logic add visual bulk. Action granularity: Statements mostly perform one action per line, with some dense conditional expressions embedded in tuple construction. Reading flow: Consistent formatting and sequential processing support natural reading, but numerous type-dependent branches and redundant elif/else clauses after returns interrupt the flow.
Run 2
Code Structure: Related encoding operations are logically grouped in a mixin with distinct methods, though the extensive imports distract from the implementation. Nesting: Parameter and multipart encoding contain several nested loops and conditionals, increasing reading effort. Clarity of intent: Docstrings, type annotations, and descriptive method names explain the purpose well; abbreviated variables such as k, vs, ft, fh, and fp and hexadecimal tuple lengths obscure details. Code length: Mostly justified by input handling, but overloads, imports, and repeated normalization logic add verbosity. Action granularity: Statements generally perform one action per line, although inline conditional expressions within tuple construction are relatively dense. Reading flow: Validation, normalization, encoding, and return steps follow a natural sequence, with whitespace and comments aiding navigation; complex branching and reused variables occasionally interrupt that flow.
Run 3
Code Structure: Methods cleanly separate URL construction, parameter encoding, and multipart encoding, although many imports are unused in this excerpt. Nesting: Encoding routines contain several nested loops and conditionals, making them harder to scan. Clarity of intent: Descriptive method names, docstrings, and type annotations explain purpose well; abbreviated variables such as ft, fh, fp, and rf, plus hexadecimal tuple lengths, obscure details. Code length: Mostly justified by input handling, but extensive imports, overloads, and repetitive normalization increase reading overhead. Action granularity: Generally one operation per line, with tuple unpacking and conditional expressions remaining reasonably focused. Reading flow: Consistent formatting and sequential processing support a natural flow, though deeply nested transformations and inline type-checking comments occasionally interrupt it.