Sample
pyint-57f9b8e629ff-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.206 | 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 | 4.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9.67 | 0–20; mean of three runs |
| BTTF | 0.282 | 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. | 6756.323 | −222.959 |
| 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.265 | −6.398 |
Intercept 8.87 + feature contributions = -134.886 (log-odds).
Score = sigmoid(-134.886) = 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.959 | +2.581 |
| 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.963 | −0.399 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.071 | +0.256 |
Intercept 0.07 + feature contributions = -1.347 (log-odds).
Score = sigmoid(-1.347) = 0.206.
| Score | 0.561 |
|---|
| Score | 96 |
|---|
Run 1
This code is extremely difficult to read. It uses cryptic single-letter variable names (h, j, l, x, y, z, A through M) that give no indication of their purpose, violating clarity of intent. Function names like 'f', 'g', and 'a' are equally opaque. The comment about 'unreachable for valid _t.DataType' is confusing. While the structure follows a logical pattern for a requests library, the naming completely obscures the intent. The code has excessive nesting in the f and g methods with multiple for loops and conditional branches. Type hints help slightly, but the variable names negate this benefit. Reading flow is completely unnatural - you must constantly refer back to declarations to understand what each letter represents. Action granularity is mixed - some lines do too much while others are overly fragmented. This reads like decompiled or obfuscated code rather than maintainable source code.
Run 2
This code is severely unreadable due to obfuscated naming (single letters like a, f, g, s, t, u, w, x, y, z, A, B, C, D, E, F, G, H, I, J, K, L, M) that conveys no semantic meaning. While structure is technically modular with methods and type hints, the logic is heavily nested (multiple for loops and conditionals) and mixes multiple actions per line. Intent is buried under cryptic variables and unclear parameter names. Type annotations help slightly, but the code reads like minified or intentionally obscured source. The functions are long, with multiple responsibilities (encoding, validation, iteration, file handling) crammed together. Reading flow is disorganized: you must constantly track what each single-letter variable holds. This is nowhere near production-grade readability despite proper imports and docstrings. Meaningful names, extracted helpers, and reduced nesting would dramatically improve clarity.
Run 3
This code is highly unreadable due to single-letter variable names (h, i, j, l, t, u, w, etc.) that obscure meaning, making clarity of intent very poor. The nesting is moderate but the logic is tangled because of these opaque names. The class mixes unrelated methods, and the structure feels disorganized. Action granularity is okay in most methods, but long chains of isinstance checks and tuple unpacking reduce readability. The reading flow is unnatural because you must constantly decode what each variable holds. Code length is acceptable, but naming and ambiguous control flow dominate the negative impression.
Run 1
Code Structure: Imports and related encoding operations are logically grouped in a mixin, with distinct methods for URL paths, parameters, and multipart bodies. Nesting: Several loops and conditionals reach four levels, making encoding logic harder to follow. Clarity of intent: Docstrings, type annotations, and library calls explain the broad purpose, but single-letter method and variable names severely obscure meaning and require constant tracing. Code length: Mostly justified by typing and supported input formats, although extensive imports and overloads increase the reading burden relative to the shown functionality. Action granularity: Most lines perform one action, with tuple unpacking and conditional expressions remaining reasonably contained. Reading flow: Each method follows a logical sequence, but opaque identifiers, variable reuse, and nested branches disrupt comprehension. Overall, sound organization and documentation are undermined primarily by poor naming.
Run 2
1. Code Structure: Imports, class methods, and encoding stages are logically organized, with responsibilities separated into distinct methods. 2. Nesting: Parameter and multipart encoding contain several nested loops and conditionals, increasing tracking effort. 3. Clarity of intent: Docstrings and type annotations explain overall purposes, but single-letter method and variable names severely obscure individual operations and data roles. 4. Code length: Implementation is reasonably compact for its functionality, although extensive imports and overload declarations add reading overhead, with many imports unused in this excerpt. 5. Action granularity: Most statements perform one action per line; tuple unpacking and inline conditional expressions introduce some density without excessive compression. 6. Reading flow: Validation followed by normalization, processing, and return provides a natural progression, but opaque naming, variable reuse, and nested conversions repeatedly interrupt comprehension.
Run 3
Code Structure: Imports and encoding responsibilities are logically grouped into a mixin with separate methods, although the multipart method combines several processing stages. Nesting: Parameter and multipart encoding use nested loops and conditionals, making some paths harder to follow. Clarity of intent: Docstrings and type annotations explain overall behavior, but single-letter method and variable names severely obscure roles and require repeated tracing. Code length: The implementation is reasonably concise for its responsibilities; extensive imports and overloads add scanning overhead but provide useful context. Action granularity: Most lines perform one action, with tuple unpacking and conditional expressions occasionally increasing cognitive load. Reading flow: Validation, normalization, encoding, and return steps generally follow a natural sequence, but opaque names, variable reuse, and deeply indented expressions interrupt that flow.