Sample
pyint-7323875deb20-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.298 | 0–1; higher is more readable |
| Mi | 0.375 | 0–1; higher is more readable |
| LLOC | 78 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.434 | 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. | 4484.187 | −147.978 |
| Source linesThe number of non-empty source lines. | 121 | +48.4 |
| 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.551 | −6.826 |
Intercept 8.87 + feature contributions = -97.534 (log-odds).
Score = sigmoid(-97.534) = 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. | 122 | −3.283 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 107 | +2.964 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 107 | −2.034 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 120.817 | +1.279 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 107.975 | +0.938 |
| 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. | 107.959 | −0.908 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.085 | +0.116 |
Intercept 0.07 + feature contributions = -0.858 (log-odds).
Score = sigmoid(-0.858) = 0.298.
| Score | 0.375 |
|---|
| Score | 78 |
|---|
Run 1
This code is essentially unreadable. Every method begins with a nonsensical self-XOR assertion pattern (e.g., if ((0xc51d ^ 0xc51d) != 0): raise AssertionError()) that always evaluates to False, adding massive noise and obscuring the actual logic. The code structure is fragmented despite being a simple wrapper class. Clarity of intent is destroyed by these pointless checks. While nesting is technically flat and action granularity is one-per-line, the reading flow is completely disrupted — every method forces the reader to mentally skip two lines of garbage before reaching meaningful code. Code length is inflated far beyond necessity. The underlying wrapper class would otherwise be straightforward, but the obfuscation pattern makes maintenance and review extremely difficult.
Run 2
The code has clear structure and follows common patterns for a request wrapper, but readability is severely degraded by redundant obfuscation: every method begins with an identical, nonsensical `if ((0xHEX ^ 0xHEX) != 0): raise AssertionError()` block. This adds ~5 lines per method, inflates code length, disrupts reading flow, and obscures the actual logic. Nesting is otherwise flat and intent is mostly clear (wrapping a PreparedRequest for cookiejar compatibility), but the repetitive dead code violates the 'concise' and 'one action per line' criteria. Removal of these blocks would bring the score much higher; as written, the code is readable only after mentally filtering out the noise.
Run 3
The code has a clear class structure and docstring, but readability is severely degraded by several factors. Every method begins with a nonsensical dead-code assertion like `if ((0xc51d ^ 0xc51d) != 0): raise AssertionError()` which adds noise and obscures intent. Nesting is minimal, but the repeated boilerplate disrupts reading flow and action granularity. The logic itself is straightforward but buried under this clutter. Methods mostly perform one conceptual action, yet the constant pseudo-assertions create multiple meaningless lines per method. Overall, the underlying design is understandable, but the presentation is heavily obfuscated.
Run 1
Code Structure: Methods are logically grouped in a focused request adapter, although imports are poorly ordered and several appear unused. Nesting: Control flow is shallow, with simple conditionals and early returns. Clarity of intent: Descriptive method names, type annotations, and the class docstring explain the adapter well; however, repeated hexadecimal XOR checks obscure intent despite always being false. Code length: These redundant checks unnecessarily inflate nearly every method, especially trivial accessors. Action granularity: Statements generally perform one action per line, and URL reconstruction is clearly formatted. Reading flow: Method ordering and straightforward implementations support natural reading, but repeated dead assertion branches interrupt the flow and distract from actual behavior.
Run 2
Code Structure: The class is logically organized into small interface methods, but imports are poorly grouped and include several unused names. Nesting: Mostly flat, with only shallow conditionals. Clarity of intent: Descriptive method names, type hints, and the class docstring clearly explain the adapter's purpose; repeated hexadecimal XOR checks obscure otherwise straightforward logic. Code length: Excessive dead-code guards substantially inflate short methods without adding meaningful behavior. Action granularity: Statements generally perform one action per line, although get_header combines nested lookups. Reading flow: Method ordering and URL reconstruction are easy to follow, but the redundant assertion branches repeatedly interrupt the flow. PreparedRequest is also referenced without a visible definition or import, leaving its annotation context unclear.
Run 3
Code Structure: The class is logically organized into small interface methods, although import grouping is inconsistent. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the adapter's purpose, but repeated hexadecimal XOR checks introduce confusing, meaningless conditions. Code length: These always-false checks substantially inflate otherwise concise methods. Action granularity: Statements generally perform one action per line; the header lookup is slightly dense but understandable. Reading flow: Related methods and properties follow a natural order, but redundant checks repeatedly interrupt the useful logic. Overall, the underlying implementation is readable, while pervasive dead-code clutter significantly reduces readability.