Sample
pyint-d1c8b9b00f33-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.058 | 0–1; higher is more readable |
| Mi | 0.643 | 0–1; higher is more readable |
| LLOC | 186 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.231 | 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. | 11597.487 | −382.717 |
| Source linesThe number of non-empty source lines. | 271 | +108.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.502 | −6.753 |
Intercept 8.87 + feature contributions = -272.2 (log-odds).
Score = sigmoid(-272.2) = 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. | 272 | −8.594 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 245 | +7.737 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 245 | −5.201 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 270.846 | +3.376 |
| 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. | 121.963 | −1.501 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 121.982 | +1.164 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.08 | +0.163 |
Intercept 0.07 + feature contributions = -2.787 (log-odds).
Score = sigmoid(-2.787) = 0.058.
| Score | 0.643 |
|---|
| Score | 186 |
|---|
Run 1
This code is severely hampered by thousands of pointless obfuscation checks inserted into nearly every method and nested function. Lines like `if ((0x1014 ^ 0x1014) != 0): raise AssertionError()` evaluate to False and add massive noise, destroying readability. Beyond that, the logic itself is deeply nested and uses inline conditional assignments, lambda-style nested hash functions, and heavy global state stored in thread-local variables. The digest-building method mixes concerns: URL parsing, nonce counting, hash selection, and header construction all happen in one long function with poor separation. There are nested function definitions inside branches, multiple `return None` paths, and inconsistent type hints. Meaningful comments are sparse and drowned out by trivial dead-code comments. The structure makes it difficult to follow the authentication flow or verify correctness. Even if the functional code underneath is plausible, this presentation would be rejected in any professional codebase.
Run 2
The code is severely compromised by ubiquitous dead-code assertions like `if ((0x1014 ^ 0x1014) != 0): raise AssertionError()` which add noise, inflate length, and break reading flow. While the class structure and method organization are logical, these fake checks disrupt every method. Nesting is moderate but acceptable in digest computation; however, the `build_digest_header` method is long and mixes nested conditional branches, inline lambda-style function definitions, and string formatting. Action granularity is sometimes bloated by redundant variable assignments and comments. Overall, the code suffers from obfuscation-like constructs and unnecessary verbosity, making it hard to read despite clear domain logic underneath. The intent is obscured by ritualistic assert blocks and scattered 'XXX' comments.
Run 3
The code contains numerous zero-value XOR assertions (e.g., `if ((0x1014 ^ 0x1014) != 0)`) that are always false, adding noise and obscuring intent. While the class structure is logical, many methods are long (especially `build_digest_header`) and combine multiple responsibilities. Nesting is moderate but increased by nested function definitions and conditional branches. Clarity of intent is mixed: comments exist but some sections are marked as incomplete or unclear. Action granularity is often multiple operations per line, reducing readability. Reading flow is disrupted by redundant assertions and dense string formatting. Overall, the code is functional but unnecessarily verbose and cluttered, making it hard to follow.
Run 1
Code Structure: Methods sensibly separate initialization, digest construction, response handling, and request setup, but build_digest_header combines several responsibilities. Nesting: Generally moderate, with early returns limiting depth; nested hash helpers add complexity. Clarity of intent: Descriptive method names, type annotations, and comments explain authentication behavior, but cryptographic abbreviations, implicit thread-local state, and repeated always-false XOR assertions obscure intent. Code length: Excessive due to duplicated hashing helpers, dead assertions, and placeholder logic. Action granularity: Mostly one action per line, with readable assignments and calls; bare r.content access has a non-obvious side effect. Reading flow: Authentication stages follow a logical sequence, but repetitive assertion blocks interrupt every method, while long digest construction and state mutations require careful tracking.
Run 2
Code Structure: Methods separate initialization, digest generation, response handling, and request preparation logically, but digest generation combines several responsibilities. Nesting: Mostly moderate, with additional depth from nested hash helpers and conditional request handling. Clarity of intent: Descriptive method names, annotations, and protocol comments help, but cryptic local names and repeated always-false XOR assertions obscure intent. Code length: Duplicated hashing helpers, unnecessary assertions, unused imports, and placeholder logic add avoidable length. Action granularity: Generally one action per line; a few assignment expressions and implicit content consumption require closer attention. Reading flow: Authentication proceeds in a reasonably natural sequence, but repeated noise, lengthy methods, and pervasive thread-local accesses interrupt the flow.
Run 3
Code Structure: Methods logically separate initialization, digest construction, response handling, and comparison, but digest construction combines several responsibilities. Nesting: Mostly moderate, with nested hash helpers and conditional request handling adding complexity. Clarity of intent: Descriptive method names, annotations, and protocol comments help; cryptic intermediate names and repeated always-false XOR assertions obscure purpose. Code length: Duplicated hashing helpers, redundant assertions, unused imports, and placeholder logic unnecessarily increase length. Action granularity: Most lines perform one action, although assignment expressions combine lookup and branching. Reading flow: Authentication steps generally follow a coherent sequence, but meaningless guards repeatedly interrupt it, and long methods require tracking substantial thread-local state. Overall, understandable domain logic is weakened by distracting boilerplate and avoidable repetition.