Sample
pyint-838b0a48e856-SRC
Unmodified source class
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 | 13.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.303 | 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.274 | −6.411 |
Intercept 8.87 + feature contributions = -131.964 (log-odds).
Score = sigmoid(-131.964) = 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.928 | +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.949 | −0.399 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.067 | +0.295 |
Intercept 0.07 + feature contributions = -1.308 (log-odds).
Score = sigmoid(-1.308) = 0.213.
| Score | 0.561 |
|---|
| Score | 96 |
|---|
Run 1
The code shows good organization with clear sectioning through imports and class methods, but has several readability issues. The type hinting is excellent and adds clarity. However, some methods are quite long and combine multiple logical operations. The _encode_files method is particularly dense with nested conditionals (4-5 levels deep) and tuple unpacking that requires careful reading. The _encode_params method has a confusing overload structure. Variable names are often too short ('p', 'k', 'v', 'fn', 'fp', 'ft', 'fh') and don't clearly communicate intent. Some lines perform multiple operations, especially in list comprehensions and tuple assignments. The error handling is clear, but the overall flow in longer methods requires careful tracking of state. While type annotations and docstrings help, the code would benefit from extracting helper methods and using more descriptive variable names. The import section is cleanly organized but very long, suggesting potential code organization issues at the module level.
Run 2
The code is functional and type-annotated, but readability is mixed. It has clear imports and docstrings, and sectioning into methods helps structure. However, there is significant nested logic, particularly in `_encode_params` and `_encode_files`, with deeply indented loops and conditionals. Multiple actions sometimes occur per line (e.g., tuple unpacking, conditional encoding), reducing clarity. Some parts are verbose due to overloads and type hints, which aid understanding but also lengthen the code. Intention is generally clear but can be obscured by repetitive type checks and defensive programming. The overall reading flow is interrupted by complex branching and long method bodies. More granular helper functions and flattening nested blocks would improve readability.
Run 3
The code is moderately readable but has several issues. The structure is logical with clear class and method separation, but the `_encode_params` method contains deep nesting (4 levels) and multiple type-checking branches that make it harder to follow. `_encode_files` is long and has complex branching. Type hints are well-used, improving clarity, and docstrings are helpful. However, the excessive use of overloaded decorators adds verbosity. Action granularity is generally good (one action per line), but there are instances of multiple operations in single lines. The reading flow is natural, though the nested loops and conditionals disrupt comprehension. The code makes good use of PEP 8 conventions and helpful comments, but the overall complexity keeps it from being truly readable.
Run 1
Code Structure: Imports, a focused mixin, and separate encoding methods provide logical organization. Nesting: Parameter and multipart encoding contain several nested loops and conditionals, increasing reading effort. Clarity of intent: Descriptive method names, docstrings, comments, and type annotations explain purpose well, though abbreviations such as k, vs, fn, fp, ft, and fh obscure local meaning. Code length: Implementation is reasonably concise for its responsibilities, but extensive imports and overload declarations add visual bulk. Action granularity: Most statements perform one action; tuple unpacking and inline conditional conversions occasionally compress multiple decisions. Reading flow: Methods generally follow natural validation, normalization, processing, and return stages. Long conditional expressions, repeated type checks, and branches accommodating multiple input formats interrupt that flow.
Run 2
Code Structure: Imports, a focused mixin, and separate encoding methods provide logical organization. Nesting: Parameter and file encoding contain several nested loops and conditionals, making some paths harder to follow. Clarity of intent: Method names, docstrings, type annotations, and targeted comments clearly explain the purpose; abbreviated variables such as k, vs, fp, ft, and fh reduce local clarity. Code length: Most implementation is concise, though extensive imports and overload declarations add reading overhead, and the multipart method could benefit from helper extraction. Action granularity: Statements generally perform one action per line, with tuple unpacking and inline conditional expressions remaining manageable. Reading flow: Validation precedes processing, and both encoding methods follow a natural sequence, but deeply nested normalization logic and numerous input-type branches occasionally interrupt the flow.
Run 3
Code Structure: Imports, a focused mixin, and separate parameter/file encoding methods provide logical organization. Nesting: Several nested loops and conditionals, especially in multipart field processing, increase cognitive load. Clarity of intent: Descriptive method names, docstrings, annotations, and explanatory comments clarify purpose, though abbreviated variables such as k, vs, ft, fh, and fp require interpretation. Code length: Mostly justified by supported input formats, but extensive imports and overload declarations add visual overhead relative to the implementation shown. Action granularity: Most lines perform a single action; tuple unpacking and inline conditional conversions remain reasonably readable. Reading flow: Validation precedes processing, and methods progress naturally toward their return values, although repeated type checks and multiline conversion expressions interrupt the flow.