Sample
pyint-8fc2acb2f957-I12
Inline all eligible single-use intermediate local variables
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.33 | 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 generally well-structured with clear docstrings, logical imports, and reasonable action granularity. Type hints and overloads enhance clarity of intent. However, readability suffers in `_encode_params` and `_encode_files` due to deep nesting (up to 4 levels), repeated isinstance checks, and complex conditional logic. The `_encode_files` method is long and mixes multiple responsibilities (validation, field encoding, file handling), making it harder to follow. Some variable names (`vs`, `ft`, `fh`, `fn`, `fp`) are cryptic. The defensive `else: return data` branch in `_encode_params` is confusing despite the comment. While not unreadable, the code could benefit from extracting helper methods and flattening nested loops.
Run 3
The code is generally readable with clear type hints, descriptive variable names, and docstrings explaining purpose. However, it has several readability issues: deep nesting in _encode_files (4 levels of indentation), multiple actions packed into single lines (ternary expressions combined with function calls), and inconsistent code structure. The import section is excessively long with many grouped imports. The _encode_params method has overloaded signatures that add complexity but are well-organized. Some conditional branches are dense, particularly the tuple unpacking logic in _encode_files. The code mixes type checking, data transformation, and error handling in ways that could be separated. While type annotations and docstrings aid understanding, the actual logic flow requires careful reading to follow.
Run 1
Code Structure: Imports are grouped sensibly, and related encoding operations are organized into focused methods within a mixin. Nesting: Parameter and multipart encoding contain several nested loops and conditionals, increasing cognitive load. Clarity of intent: Descriptive method names, docstrings, comments, and type annotations explain purpose well, although abbreviated variables such as ft, fh, fp, and rf obscure details. Code length: Most implementation is justified, but extensive imports and overload declarations add visual bulk relative to the excerpt's functionality. Action granularity: Statements generally perform one action per line; tuple unpacking and inline conditional expressions are reasonable but occasionally dense. Reading flow: Methods follow a natural validation, normalization, encoding, and return sequence. Repeated normalization logic, redundant elif branches after returns, and multiline conditional expressions slightly interrupt that flow.
Run 2
Code Structure: Imports and related encoding operations are logically grouped in a cohesive mixin, though the extensive import block distracts from this excerpt. Nesting: Parameter and file encoding contain several nested loops and conditionals, making some paths harder to follow. Clarity of intent: Descriptive method names, docstrings, type annotations, and targeted comments explain purpose well; abbreviated variables such as k, vs, ft, fh, and fp reduce local clarity. Code length: Mostly justified by input flexibility, but overload declarations and repeated normalization logic add verbosity. Action granularity: Statements generally perform one action per line, with tuple construction and conditional expressions remaining reasonably readable. Reading flow: Validation, normalization, encoding, and return steps follow a natural sequence; polymorphic input handling and deeply indented expressions occasionally interrupt that flow.
Run 3
Code Structure: Responsibilities are logically grouped into a mixin with focused methods, though the extensive imports add overhead. Nesting: Parameter and file encoding contain nested loops and conditionals, reaching several levels and making transformations harder to follow. Clarity of intent: Method names, docstrings, annotations, and explanatory comments clearly describe the purpose; abbreviated variables such as ft, fh, fp, and rf reduce local clarity. Code length: Mostly justified by supported input formats and typing, but overload declarations and repeated normalization logic add verbosity. Action granularity: Statements generally perform one action per line, with readable formatting for complex expressions. Reading flow: Validation precedes processing, and encoding follows a natural sequence; inline conditional expressions, redundant elif branches after returns, and reused variables slightly interrupt the flow.