Sample
pyint-9603ff0fba0d-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.198 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 102 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.33 | 0–20; mean of three runs |
| BTTF | 0.203 | 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. | 7055.986 | −232.848 |
| Source linesThe number of non-empty source lines. | 220 | +88 |
| 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.297 | −6.445 |
Intercept 8.87 + feature contributions = -142.423 (log-odds).
Score = sigmoid(-142.423) = 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. | 221 | −6.789 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 203 | +6.284 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 203 | −4.237 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 219.928 | +2.664 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.543 | +0.737 |
| 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.973 | −0.4 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.069 | +0.271 |
Intercept 0.07 + feature contributions = -1.399 (log-odds).
Score = sigmoid(-1.399) = 0.198.
| Score | 0.561 |
|---|
| Score | 102 |
|---|
Run 1
The code has a clear class structure and type annotations, but contains several readability issues. The presence of dead code blocks like 'if ((0xc14c ^ 0xc14c) != 0): raise AssertionError()' is confusing and serves no functional purpose, making the code harder to understand. Function lengths are moderate but _encode_files could be broken into smaller helper functions for clarity. Nesting levels are acceptable, with most logic staying within 2-3 levels. The docstrings are helpful and descriptive. The method names and variable names are generally clear. However, the mixing of different type checks (isinstance checks, hasattr checks) creates some cognitive load. The code imports many modules, which is expected for this kind of utility class but adds visual noise. The action granularity is mostly good with one operation per line. Overall, the code is maintainable but would benefit from removing dead code and splitting complex functions.
Run 2
The code demonstrates moderate readability with clear organization of imports and well-documented methods. However, several issues reduce clarity: dead code like 'if ((0xc14c ^ 0xc14c) != 0): raise AssertionError()' is confusing and should be removed. Method lengths are excessive, particularly _encode_params and _encode_files, which contain multiple nested loops and conditionals. The _encode_files method has deeply nested logic for handling different file tuple formats, making it difficult to follow. Type hints are extensive but sometimes obscure rather than clarify. Variable names like 'fh', 'rf', and '_t' are cryptic. Action granularity is inconsistent - some lines pack multiple operations. The decode-line syntax for conditional encoding '(k.encode("utf-8") if isinstance(k, str) else k)' appears repeatedly and is hard to parse. Reading flow is interrupted by the need to mentally track multiple state variables through nested loops. Overall, functional but not exemplary code clarity.
Run 3
The code has clear structure at the top level but suffers from several readability issues. The numerous if ((0xc14c ^ 0xc14c) != 0): raise AssertionError() blocks are useless obfuscation that adds noise without value. Deep nesting in _encode_params and _encode_files creates cognitive overhead, especially in the file handling loop that reaches 4 levels of indentation. While type hints and docstrings are helpful, the variable names are cryptic (p, k, v, fn, fp, ft, fh) and lack descriptive intent. Multiple actions are crammed into single lines, particularly in the circular XOR checks. The overloading of _encode_params adds complexity that interrupts reading flow. Action granularity is inconsistent - some lines do too much, while others are just noise. The code would benefit from extracting helper methods, removing dead code, and using more descriptive variable names.
Run 1
Code Structure: Imports and encoding methods are logically grouped, with distinct responsibilities. Nesting: Parameter and multipart processing use several nested loops and conditionals, making some branches harder to follow. Clarity of intent: Method names, docstrings, and type annotations explain the purpose well, but abbreviated variables such as ft, fh, fp, and rf obscure details. The always-false hexadecimal XOR assertions add confusing, purposeless noise. Code length: Most logic is justified, although overloads, repeated conversion patterns, and dead assertions increase scanning effort. Action granularity: Statements generally perform one action per line; tuple unpacking and conditional expressions remain reasonably readable. Reading flow: Validation followed by normalization, encoding, and return provides a natural progression, but nested transformations and irrelevant assertions interrupt it.
Run 2
Code Structure: Methods are logically grouped in an encoding mixin, with organized imports and clear separation of URL, parameter, and multipart handling. Nesting: Parameter and file encoding contain moderately deep loops and conditionals that increase reading effort. Clarity of intent: Descriptive method names, type annotations, and docstrings explain purpose well, but abbreviated variables such as ft, fh, fp, and rf reduce clarity. Repeated always-false hexadecimal XOR checks introduce distracting, unexplained dead code. Code length: Most implementation is justified, though extensive imports, overload declarations, and redundant checks make this excerpt longer to scan. Action granularity: Statements generally perform one action per line; tuple unpacking and inline conditional conversions remain reasonably readable. Reading flow: Validation, normalization, encoding, and return steps follow a natural sequence, but nested conversions, variable reuse, and irrelevant assertions interrupt that flow.
Run 3
Code Structure: Imports and encoding methods are logically grouped, with distinct responsibilities, though multipart handling could be split into helpers. Nesting: Parameter and field encoding use several nested loops and conditionals, making transformations harder to follow. Clarity of intent: Docstrings, type annotations, and descriptive method names explain the purpose well; abbreviated variables such as ft, fh, fp, and rf obscure details. Repeated XOR checks that are always false introduce meaningless distractions. Code length: Mostly justified by supported input formats, but overloads, verbose imports, and dead assertion blocks increase scanning effort. Action granularity: Statements generally perform one action per line; tuple unpacking and inline conditional conversions are reasonably contained. Reading flow: Processing follows a natural validation-to-normalization-to-encoding sequence, but nested branching and irrelevant checks interrupt that flow.