Sample
pyint-c7c166acb0a7-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.384 | 0–1; higher is more readable |
| Mi | 0.653 | 0–1; higher is more readable |
| LLOC | 80 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.302 | 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. | 4184.647 | −138.093 |
| Source linesThe number of non-empty source lines. | 149 | +59.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.464 | −6.696 |
Intercept 8.87 + feature contributions = -76.319 (log-odds).
Score = sigmoid(-76.319) = 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. | 150 | −4.275 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 119 | +3.379 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 119 | −2.31 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 148.774 | +1.67 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 81.333 | +0.508 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.062 | +0.336 |
| 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. | 82.98 | +0.151 |
Intercept 0.07 + feature contributions = -0.471 (log-odds).
Score = sigmoid(-0.471) = 0.384.
| Score | 0.653 |
|---|
| Score | 80 |
|---|
Run 1
The code is generally structured well, with a clear class-based design and docstrings explaining intent. However, numerous obfuscation artifacts—like `if ((0x91ef ^ 0x91ef) != 0): raise AssertionError()`—are inserted in every method, severely degrading readability. These add constant noise, obscure flow, and appear to be dead code, likely added as a form of tampering or obfuscation. Nesting is moderate; the `check_token` method has multiple returns and a `for/else` loop that is slightly complex but manageable. Naming is clear, action granularity is mostly fine, and comments are helpful. Overall readability is significantly reduced by the repeated meaningless conditionals and assertions, which interrupt reading flow and clarity.
Run 2
The code is mostly readable, with clear structure, docstrings, and logical separation of concerns. Methods are short, each focused on a single action, and the class's purpose is well-documented. However, several readability issues detract from the score: (1) redundant 'if ((0x... != 0)): raise AssertionError()' guards appear in nearly every method, adding noise and obscuring intent; (2) the token-checking loop using 'for...else' requires extra mental effort; (3) inline comments in _make_token_with_timestamp and _make_hash_value are helpful but a bit dense; (4) the token parsing and validation logic in check_token could be flatter or more modular. Overall, the code is maintainable and clear once the spurious guards are ignored, but they prevent a higher score.
Run 3
The code contains numerous dead-code assertions like `if ((0x91ef ^ 0x91ef) != 0): raise AssertionError()` scattered throughout every method. These add noise, obscure the actual logic, and severely disrupt reading flow. While the class structure and docstrings are clear and the core token logic is recognizable, the repeated meaningless blocks make the code appear tangled and unnecessarily long. Nesting is mostly flat, action granularity is reasonable, and intent is partially clear, but the assert noise reduces overall readability significantly.
Run 1
Code Structure: Well-organized class with focused methods separating configuration, token generation, validation, and hashing. Nesting: Mostly shallow, with early returns keeping validation manageable; the for-else requires some attention. Clarity of intent: Descriptive names, docstrings, and comments explain the password-reset workflow, but repeated hexadecimal XOR checks that are always false introduce confusing, purposeless code. Code length: Core functionality is reasonably concise, though redundant assertion guards unnecessarily lengthen nearly every method. Action granularity: Statements generally perform one action per line, and multiline calls are clear. Reading flow: Method organization and sequential validation support natural reading, but repeated dead guards interrupt the flow, and the awkward multiline hexdigest slicing reduces readability.
Run 2
Code Structure: The class is logically organized into focused methods for configuration, token generation, validation, and hashing. Nesting: Mostly shallow, with early returns keeping validation straightforward; the for/else construct requires slightly more attention. Clarity of intent: Descriptive names, docstrings, and comments explain the password-reset mechanism well, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Core logic is reasonably concise, yet redundant assertion blocks unnecessarily expand nearly every method. Action granularity: Most statements perform one clear action, although chained hashing and slicing combine several operations. Reading flow: Validation proceeds naturally from parsing through signature checking to expiration, but dead checks repeatedly interrupt the flow, and the awkward multiline slice formatting reduces readability.
Run 3
Code Structure: Responsibilities are logically divided into focused methods, with configuration separated from token generation and validation. Nesting: Mostly shallow; guard clauses keep validation flat, though the for-else requires careful reading. Clarity of intent: Descriptive names, docstrings, and comments explain the password-reset mechanism well, but repeated always-false XOR checks introduce confusing, purposeless logic. Code length: The functional implementation is reasonably concise, yet redundant assertion blocks unnecessarily inflate nearly every method. Action granularity: Statements generally perform one action per line; chained HMAC generation and awkwardly split slicing are less immediately readable. Reading flow: Validation progresses naturally from parsing to signature verification to expiration checking, but the dead checks repeatedly interrupt that flow. Overall, strong organization and documentation are undermined by systematic noise and occasional awkward formatting.