Sample
pyint-05cb3c018c91-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.215 | 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 | 6.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10 | 0–20; mean of three runs |
| BTTF | 0.339 | 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. | 6688.447 | −220.719 |
| 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.285 | −6.427 |
Intercept 8.87 + feature contributions = -132.676 (log-odds).
Score = sigmoid(-132.676) = 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.065 | +0.308 |
Intercept 0.07 + feature contributions = -1.296 (log-odds).
Score = sigmoid(-1.296) = 0.215.
| Score | 0.561 |
|---|
| Score | 96 |
|---|
Run 1
The code is difficult to read due to poor naming, unclear intent, and tangled structure. Variables like 'age', 'map', 'date', 'limit', 'step', 'node', 'size', and 'score' have no semantic relationship to their actual roles, masking the logic. Methods 'validateClient' and 'validateOrder' do not reveal their purpose (URL building, encoding, multipart body creation). The code mixes actions and conditions, with multiple operations per line and many nested blocks. Although some docstrings and type hints exist, they do not offset the confusing variable choices and misleading names. Long methods and fragmented imports further reduce readability.
Run 2
This code is extremely difficult to read due to heavily obfuscated naming. Variables like 'age', 'map', 'date', 'limit', 'node', 'step', 'score', and 'item' have no semantic relationship to their actual roles (URL parts, request data, files, etc.). Function names like 'findItem', 'validateClient', and 'validateOrder' are misleading—they actually build URLs, encode parameters, and construct multipart bodies. The logic is tangled; for example, validateOrder mixes data conversion, file handling, and multipart encoding in one long method with multiple nested loops and conditional branches. While the code follows a single-action-per-line style in places and type hints are present, the complete loss of meaningful naming and intent makes it nearly unreadable. The original purpose (likely from the 'requests' library) is obscured. The structure is not logically organized around clear domain concepts, and the reading flow is completely unnatural. This would be extremely hard to maintain or debug.
Run 3
The code has a clear class structure and type hints, but readability is severely undermined by obfuscated identifier names that break the mapping between names and intent (e.g., 'findItem' for building a URL path, 'validateClient' for encoding parameters, 'validateOrder' for multipart encoding, and variables like 'age', 'map', 'date', 'count', 'price', 'score', 'node', 'step'). Abbreviations and generic names obscure purpose. Nesting is moderate; there are several nested loops and conditionals, and the action granularity is mixed, with multiple actions per line in places. The reading flow is disrupted by the misleading names and type-checking branches. Overall, the structure is logical but the naming makes the code much harder to understand than necessary.
Run 1
Code Structure: Imports and encoding operations are logically grouped into a mixin with separate methods, although the import block is disproportionately large for this excerpt. Nesting: Parameter and multipart processing contain several nested loops and conditionals, increasing cognitive load. Clarity of intent: Docstrings and type annotations explain the overall purpose, but misleading names such as findItem, validateClient, age, map, and pendingIndex obscure URL, field, and file semantics; map also shadows a builtin. Code length: Mostly justified by supported input formats, though overloads and repeated normalization logic add verbosity. Action granularity: Generally one operation per statement, with readable multiline expressions; conditional tuple construction requires closer inspection. Reading flow: Methods proceed naturally from validation through normalization to encoding, but unrelated variable names, inconsistent naming conventions, and reassignment of inputs make the data flow harder to follow.
Run 2
Code Structure: Imports, a mixin, and separate methods provide logical organization, though the extensive import block distracts from the implementation. Nesting: Encoding methods contain several nested loops and conditionals, increasing reading effort. Clarity of intent: Docstrings and recognizable library calls explain the broad purpose, but misleading names such as validateClient, validateOrder, age, map, and score obscure what operations and values represent; map also shadows a built-in. Code length: The implementation is reasonably compact for its functionality, but overload declarations and lengthy imports add overhead. Action granularity: Most statements perform one action, with tuple unpacking and inline conversions remaining manageable. Reading flow: Processing follows a sensible sequence from validation through normalization to encoding, but inconsistent naming, variable reassignment, and dense conditional expressions interrupt comprehension.
Run 3
Code Structure: Imports, a mixin, and separate methods provide logical organization, although many imports are unused in this excerpt. Nesting: Parameter and multipart encoding contain several nested loops and conditionals that increase reading effort. Clarity of intent: Docstrings and type annotations explain the broad purpose, but misleading names such as validateClient, validateOrder, age, map, and score obscure actual roles; map also shadows a built-in. Code length: The implementation is reasonably compact for its functionality, though extensive imports and overloads add visual bulk. Action granularity: Most statements perform one action per line, and multiline expressions are formatted consistently. Reading flow: Early checks and sequential processing help, but unrelated variable names, reassignment of parameters to different representations, and inconsistent naming conventions force readers to repeatedly consult surrounding context.