Sample
pyint-064fb432e990-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.212 | 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 | 5.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.374 | 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.319 | −6.478 |
Intercept 8.87 + feature contributions = -134.967 (log-odds).
Score = sigmoid(-134.967) = 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.969 | +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.958 | −0.399 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.067 | +0.289 |
Intercept 0.07 + feature contributions = -1.314 (log-odds).
Score = sigmoid(-1.314) = 0.212.
| Score | 0.561 |
|---|
| Score | 96 |
|---|
Run 1
The code has some good structure with type hints and docstrings, but readability suffers from poor naming conventions. Variables like 'p2', 'pat', 'que', 'dat5', 'k2', 'vs2', 'v2', 'fil', 'dat6', 'fie', 'fie2', 'val2', 'v3', 'k3', 'fn2', 'fp2', 'ft2', 'fh2', 'fda', 'rf2', 'bod' are cryptic and non-descriptive, making the logic hard to follow. The encode7 method is particularly long (50+ lines) with nested loops and multiple conditional branches (2-3 levels deep), violating single-responsibility and flat nesting principles. Overloads for encode6 add complexity. The encode6 method has reasonable flow but still uses unclear variable names. Multiple abbreviations obscure intent. While imports are organized and there is type annotation, the overall readability is significantly compromised by poor variable naming, excessive abbreviations, lengthy methods, and deep nesting.
Run 2
The code has some redeeming qualities - type hints, docstrings, and a clear import structure - but suffers from severely degraded readability due to poor naming conventions. Variables like 'dat5', 'dat6', 'k2', 'vs2', 'v2', 'v3', 'fn2', 'fp2', 'ft2', 'fh2', 'p2', 'pat', 'que', 'url2', and method names like 'encode6', 'encode7', 'path2' provide no semantic meaning. This obscures the intent of operations throughout the code. While the structure maintains reasonable nesting levels and the logic flows in a somewhat linear fashion, the cryptic naming forces readers to mentally track obscure variable references, essentially requiring a decoder ring. The functional organization is acceptable, but the deliberate obfuscation of names - appearing to be pattern-based renaming - makes this code practically unreadable for maintenance purposes. The docstrings help somewhat, but cannot compensate for semantically void identifiers in core logic. Action granularity is reasonable with one operation per line, and the reading flow is sequential, but the constant mental translation of meaningless names makes comprehension extremely difficult.
Run 3
The code is highly unreadable due to confusing variable naming (dat5, dat6, k2, vs2, v3, fie2, etc.), which obscures intent despite docstrings. Nesting is deep in loops and conditionals, making flow hard to follow. Multiple actions occur per line in several places, reducing clarity. The encode6 method relies on overloads and type ignores that complicate understanding. Structure is cluttered with many imports and mixed responsibilities. While some formatting is consistent, the overall reading flow is poor because identifiers are cryptic and data transformations span many lines without clear intermediate steps.
Run 1
1. Code Structure: Imports, a focused mixin, and separate URL, parameter, and multipart methods provide logical organization. 2. Nesting: Encoding methods contain multiple nested loops and conditionals, making some execution paths harder to follow. 3. Clarity of intent: Docstrings, comments, and type annotations explain the broad purpose, but names such as path2, encode6, dat5, fie2, and fp2 obscure meaning and relationships. 4. Code length: Mostly justified by input handling and typing overloads, although repetitive conversions and verbose formatting increase reading effort. 5. Action granularity: Generally one operation per line, with clear assignments and calls; embedded conditional expressions add some density. 6. Reading flow: Processing proceeds naturally from validation through normalization to encoding, but abbreviated numbered identifiers, reused variables, and nested branches interrupt comprehension.
Run 2
Code Structure: Imports and related encoding methods are logically grouped within a mixin, with distinct responsibilities. Nesting: Parameter and multipart encoding contain several nested loops and conditionals, making some paths harder to follow. Clarity of intent: Docstrings, type annotations, and library calls explain the overall purpose, but cryptic names such as encode6, encode7, dat5, fie2, and ft2 obscure individual operations. Code length: Mostly justified by supported input formats, though extensive imports and overload declarations add visual overhead relative to the shown implementation. Action granularity: Statements generally perform one action per line; tuple unpacking and inline conditional conversions remain reasonably compact. Reading flow: Validation, normalization, encoding, and return steps follow a natural sequence, but reused variables and numbered identifiers require frequent backtracking to track their meanings.
Run 3
Code Structure: Methods logically separate URL construction, parameter encoding, and multipart encoding, with organized imports and useful type annotations. Nesting: Encoding methods contain several nested loops and conditionals, making some paths harder to follow. Clarity of intent: Docstrings explain overall purposes, but names such as path2, encode6, dat5, fie2, and ft2 obscure individual roles. Code length: Mostly justified by supported input formats, though overloads and verbose formatting add reading overhead. Action granularity: Statements generally perform one action per line; tuple unpacking and conditional expressions remain reasonably focused. Reading flow: Validation precedes processing and methods progress toward clear return values, but variable reuse, inconsistent abbreviations, and deeply nested conversions interrupt the flow. Overall, the organization is sound, but poor naming significantly reduces readability.