Sample
pyint-9aa377759982-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.355 | 0–1; higher is more readable |
| Mi | 0.559 | 0–1; higher is more readable |
| LLOC | 96 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.33 | 0–20; mean of three runs |
| BTTF | 0.464 | 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. | 6847.293 | −225.961 |
| Source linesThe number of non-empty source lines. | 166 | +66.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.519 | −6.778 |
Intercept 8.87 + feature contributions = -157.469 (log-odds).
Score = sigmoid(-157.469) = 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. | 167 | −4.877 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 157 | +4.693 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 157 | −3.182 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 165.739 | +1.907 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.946 | +0.598 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.075 | +0.209 |
| 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. | 86.94 | −0.017 |
Intercept 0.07 + feature contributions = -0.598 (log-odds).
Score = sigmoid(-0.598) = 0.355.
| Score | 0.559 |
|---|
| Score | 96 |
|---|
Run 1
The code has reasonable structure with clear sections and docstrings but loses points due to several issues. The presence of dead code (redundant `if ((0xb6f5 ^ 0xb6f5) != 0): raise AssertionError()` blocks) is confusing and adds unnecessary noise, severely impacting readability. The `__init__` method is moderately complex but logically organized with clear comments explaining business rules. Nesting is flat and good. Intent is generally clear for methods like `get_context`, but the boolean logic for `can_change_related`, `can_delete_related`, and `can_view_related` could be more explicit. Action granularity is mostly good. Reading flow is acceptable but interrupted by the dead assertion blocks. Length is reasonable for a Django widget wrapper. Overall, the code would be clearly above average without the dead code, but as written it appears suspicious or obfuscated.
Run 2
The code shows clear intent and follows Django conventions, but readability is severely hampered by repetitive dead-code assertions like `if ((0xb6f5 ^ 0xb6f5) != 0): raise AssertionError()` that appear in nearly every method. These lines add noise and break the natural reading flow. The class structure is logical, nesting is mostly flat, and individual actions are generally on separate lines, but the excessive boilerplate makes the code unnecessarily long and distracts from the core logic. Variable names and docstrings are reasonably clear, and methods like `get_context` are well-organized, but the overall impression is cluttered. Removing the redundant assertions would significantly improve readability and bring the score closer to 16-18.
Run 3
The code has some redeeming qualities: consistent indentation, clear method names, and a logical class-based structure. However, it is severely undermined by several critical issues. The most egregious is the repeated dead-code assertions (`if ((0xb6f5 ^ 0xb6f5) != 0): raise AssertionError()`) scattered throughout every method. These add noise, interrupt reading flow, and obscure the actual logic. The `__init__` method is overly long and performs multiple unrelated configurations, violating action granularity. Some variables, like `supported`, are not self-documenting. The `get_context` method builds a URL parameter string with a generator expression, which reduces clarity compared to a more straightforward approach. While the docstring and overall organization are standard, the pervasive junk code and dense initialization make the code difficult to scan and understand, significantly harming readability.
Run 1
Code Structure: Logically organized into a widget wrapper with focused methods and properties, though several imports appear unused. Nesting: Mostly flat, with shallow conditionals and no deeply nested control flow. Clarity of intent: Descriptive names, a class docstring, and explanatory comments clarify the wrapper's purpose, but repeated hexadecimal XOR checks obscure intent despite always being false. Code length: Delegation methods are concise, but redundant assertion blocks substantially inflate the class, especially its simple accessors. Action granularity: Statements generally perform one action per line, and multiline calls and dictionaries are formatted clearly. Reading flow: Initialization, delegation, URL generation, and context construction follow a reasonable progression; however, meaningless checks interrupt every method and force readers to distinguish noise from actual behavior.
Run 2
Code Structure: The class is logically organized into initialization, properties, context construction, and delegation methods. Nesting: Control flow is shallow, with straightforward conditionals. Clarity of intent: Descriptive names and comments explain the widget wrapper, but repeated hexadecimal XOR checks that are always false introduce confusing, purposeless code. Code length: These checks substantially inflate otherwise concise methods; several unused imports also add clutter. Action granularity: Statements generally perform one action per line, and multiline calls and dictionaries are formatted clearly. Reading flow: The progression is natural, but redundant assertion blocks repeatedly interrupt it. Overall, the underlying implementation is readable, while artificial boilerplate significantly reduces clarity and concision.
Run 3
Code Structure: The class is logically organized into initialization, delegated properties, URL generation, and context construction. Nesting: Control flow is shallow, with straightforward conditionals and no deeply nested blocks. Clarity of intent: Descriptive method names, permission flags, and explanatory comments convey the widget wrapper's purpose, but repeated hexadecimal XOR checks obscure intent with meaningless dead branches. Code length: Most functional code is reasonably concise, though the redundant assertions significantly inflate short delegation methods, and several imports are unused in this snippet. Action granularity: Statements generally perform one action per line; multiline expressions and dictionaries are formatted clearly. Reading flow: Related operations are grouped naturally, and context construction progresses logically, but every method's unnecessary assertion interrupts the flow. Overall, the underlying implementation is readable, with substantial avoidable noise.