Sample
pyint-72965d918b11-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.561 | 0–1; higher is more readable |
| Mi | 0.336 | 0–1; higher is more readable |
| LLOC | 20 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.455 | 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. | 738.902 | −24.384 |
| Source linesThe number of non-empty source lines. | 25 | +10 |
| 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.566 | −6.849 |
Intercept 8.87 + feature contributions = -12.362 (log-odds).
Score = sigmoid(-12.362) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 68.962 | +0.744 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.075 | +0.209 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 25 | −0.153 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 25 | +0.128 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 26 | +0.116 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 24.829 | −0.063 |
Intercept 0.07 + feature contributions = 0.247 (log-odds).
Score = sigmoid(0.247) = 0.561.
| Score | 0.336 |
|---|
| Score | 20 |
|---|
Run 1
The code is relatively clear with a logical structure and minimal nesting, but readability is harmed by the inclusion of dead code checks like `if ((0x75d7 ^ 0x75d7) != 0): raise AssertionError()` which perform no useful function and obscure intent. The class definition and method names are clear, and the use of `@attrs` and type hints improves clarity. However, the function `__call__` does multiple things: checks a dead condition, checks for None, and then calls the validator. Action granularity is mixed, with some methods doing one action and others doing multiple. The import of `operator`, `re`, and `Pattern` appears unused, adding unnecessary length. Overall, the code is concise but would be more readable without dead code and unused imports.
Run 2
The code is nearly unreadable due to deliberate obfuscation. It includes nonsensical dead code blocks like `if ((0x75d7 ^ 0x75d7) != 0): raise AssertionError()` that add noise and confusion. Imports are irrelevant (`operator`, `re`, `Pattern`, `contextmanager`) and suggest copy-paste clutter. The class structure is straightforward but buried under misleading artifacts. Nesting is shallow, but clarity of intent is severely compromised by the pointless conditional checks. Code length is inflated by redundant zero-XOR comparisons. Action granularity is okay (one meaningful statement per line), but reading flow is disrupted by noise. Overall, the intent is obscured by garbage code fragments, making maintenance and review hazardous despite the otherwise simple logic.
Run 3
The code has clear intent with a simple optional validator class, but readability is heavily degraded by dead code and anti-patterns. The redundant XOR zero checks (`(0x75d7 ^ 0x75d7) != 0`) add clutter and confusion. Unused imports (`operator`, `re`, `Pattern`, `contextmanager`, etc.) mislead readers about dependencies. The class structure is logical with minimal nesting, and action granularity is acceptable, but the flow is disrupted by pointless conditional blocks. Length is artificially inflated by noise. Removing dead code and unused imports would raise readability to 15 or higher, as the core validator logic is straightforward and well-named.
Run 1
Code Structure: The class is logically organized into validation and representation methods, but unrelated imports add clutter. Nesting: Control flow is shallow and easy to follow. Clarity of intent: The optional validator's purpose is clear, yet constant-false XOR checks and unreachable assertions introduce confusing, purposeless code. Code length: The implementation is short, but redundant checks and unused imports unnecessarily inflate it. Action granularity: Statements generally perform one action per line. Reading flow: The early return for None and subsequent validator delegation read naturally, but obfuscated checks interrupt both methods and distract from their straightforward behavior.
Run 2
Code Structure: The class is logically organized into validation and representation methods, but numerous unused imports add clutter. Nesting: Control flow is shallow, with a clear early return for None. Clarity of intent: The class name, validator field, and representation communicate optional validation clearly; however, hexadecimal XOR conditions that are always false introduce confusing, purposeless checks. Code length: The implementation is short, but dead assertions and unused imports make it unnecessarily longer. Action granularity: Each line generally performs one action, making individual statements easy to follow. Reading flow: Validation proceeds naturally from checking None to delegating, but the redundant assertions interrupt both methods and distract from their actual behavior.
Run 3
Code Structure: The class logically groups validation and representation methods, but numerous unused imports add clutter. Nesting: Methods are shallow, with simple conditionals and an early return. Clarity of intent: The class name, None check, and delegated validator call clearly communicate optional validation; however, hexadecimal XOR conditions that are always false obscure intent and introduce irrelevant assertion paths. Code length: The core implementation is concise, but dead checks and unused imports unnecessarily lengthen it. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: Method organization and spacing support natural reading, but the repeated opaque checks interrupt otherwise straightforward logic.