Sample
pyint-b0d43fbb9c3a-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.125 | 0–1; higher is more readable |
| Mi | 0.729 | 0–1; higher is more readable |
| LLOC | 93 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.267 | 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. | 6623.5 | −218.575 |
| Source linesThe number of non-empty source lines. | 202 | +80.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.202 | −6.303 |
Intercept 8.87 + feature contributions = -135.209 (log-odds).
Score = sigmoid(-135.209) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 202 | +6.25 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 203 | −6.151 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 202 | −4.214 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 201.925 | +2.413 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 78.946 | +0.321 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.079 | +0.171 |
Intercept 0.07 + feature contributions = -1.945 (log-odds).
Score = sigmoid(-1.945) = 0.125.
| Score | 0.729 |
|---|
| Score | 93 |
|---|
Run 1
The code demonstrates moderate readability. The structure is logical with clear separation of imports, class definition, and methods, but it suffers from several issues. The nesting in `_encode_params` and `_encode_files` creates complexity with multiple levels of conditionals and loops. Some methods have unused or unnecessary blank lines after docstrings. The action granularity is mixed - some lines pack multiple operations while others are appropriately separated. The intent is generally clear due to naming conventions, but the heavy use of type hints and overloads adds visual noise. The `_encode_files` method is particularly long and complex, handling multiple file format variations in a single method. The imports section is extensive and well-organized, but the overall code density is high. The reading flow is interrupted by the complexity of type annotations and the unpacking logic in file handling. While the code follows Python conventions, the complexity of the logic makes it harder to follow than necessary.
Run 2
The code is moderately readable but has several issues. The imports are extensive and well-organized, though poorly formatted (missing commas, incorrect indentation). The class structure is logical, but methods are overly long - particularly _encode_files which mixes multiple responsibilities and levels of abstraction. Nesting is acceptable in most places but becomes deep in the file-processing loop with nested conditionals and tuple unpacking. Variable names are mostly clear (path, query, fields, files) but some are cryptic (_t, fh, ft, rf). Action granularity is inconsistent - some lines are concise while others pack multiple operations. The blank lines and empty function bodies (containing only whitespace) hint at missing docstrings. Type hints are present but complex overloads add noise. The _encode_params method has redundant branching with elif chains that could be simplified. Reading flow is disrupted by the long _encode_files method and inconsistent formatting throughout.
Run 3
The code is generally well-structured with clear imports, organized methods, and type hints that enhance clarity. The class methods follow logical flow and keep actions reasonably granular. However, readability is impacted by a few deeply nested loops and conditional branches, particularly in _encode_params and _encode_files. Some blocks contain multiple assertions or variable assignments per line, which slightly reduces scanability. The use of overloads and static methods is clear but adds complexity. While the intent is mostly evident, certain ambiguous patterns (e.g., mixed tuple/list handling for file descriptors) require close reading. Overall, the code is above average but not exceptionally readable due to moderate nesting and occasional density.
Run 1
Code Structure: Imports and related encoding methods are logically organized within a mixin, although the extensive import block distracts from the implementation. Nesting: Most control flow is manageable, but parameter and multipart encoding contain nested loops and conditionals that require careful tracking. Clarity of intent: Method names, type annotations, and explicit validation communicate purpose well; abbreviated variables such as k, vs, fn, fp, ft, and fh and absent explanatory documentation obscure details. Code length: Implementations are reasonably concise, but overload declarations and excess blank lines interrupt compactness. Action granularity: Statements generally perform one action each, with tuple unpacking and inline conditional conversions adding some density. Reading flow: Methods progress naturally from validation through normalization to encoding, though repeated branching, reused variables, and multiline expressions make some sections slower to follow.
Run 2
Code Structure: Imports are grouped, and a cohesive mixin separates URL construction, parameter encoding, and multipart encoding into focused methods. Nesting: Parameter and field processing contain several nested loops and conditionals, making some paths harder to follow. Clarity of intent: Descriptive method names and type annotations communicate purpose, but abbreviated variables such as k, vs, ft, fh, and fp, plus missing explanatory comments, obscure multipart details. Code length: Mostly justified by supported input formats, although overload declarations and verbose conversion expressions add reading overhead. Action granularity: Generally one operation per line, with clear intermediate assignments; inline conditional conversions are somewhat dense. Reading flow: Methods follow a logical validation-to-transformation-to-return progression, but excessive blank lines, trailing whitespace, and repeated branching interrupt the flow.
Run 3
Code Structure: Imports are grouped logically, and encoding responsibilities are separated into focused methods within a mixin. Nesting: Parameter and field encoding contain several nested loops and conditionals, making those sections harder to follow. Clarity of intent: Method names and type annotations communicate purpose, but abbreviated variables such as k, vs, fn, fp, ft, and fh obscure details; documentation would help explain supported input forms. Code length: Generally proportionate to the functionality, although overload declarations, extensive imports, and unnecessary blank lines increase scanning effort. Action granularity: Statements generally perform one action each, with no compressed multi-statement lines; inline conditional expressions add some complexity. Reading flow: Validation, normalization, encoding, and return steps follow a natural sequence, but inconsistent whitespace and dense tuple construction interrupt the flow.