Sample
pyint-93e513b1d08a-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.013 | 0–1; higher is more readable |
| Mi | 0.802 | 0–1; higher is more readable |
| LLOC | 244 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.472 | 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. | 19530.592 | −644.51 |
| Source linesThe number of non-empty source lines. | 517 | +206.8 |
| 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.256 | −6.383 |
Intercept 8.87 + feature contributions = -435.223 (log-odds).
Score = sigmoid(-435.223) = 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. | 518 | −17.304 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 474 | +15.658 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 474 | −10.456 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 516.798 | +6.814 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.112 | +0.601 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.063 | +0.326 |
| 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. | 87.954 | −0.06 |
Intercept 0.07 + feature contributions = -4.352 (log-odds).
Score = sigmoid(-4.352) = 0.013.
| Score | 0.802 |
|---|
| Score | 244 |
|---|
Run 1
The code has a clear overall structure with logical method organization, but readability is severely impacted by numerous issues. The most glaring problem is the presence of nonsensical dead code checks like `if ((0x583a ^ 0x583a) != 0): raise AssertionError()` scattered throughout every method, which adds noise and confusion. The code is moderately nested but generally follows one-action-per-line principles. Method names are descriptive and show clear intent, and the class hierarchy is well-structured following Django conventions. However, the file starts with excessive imports, many unused in the shown code. Some methods like _check_unique_target are long and complex with conditional logic that could be broken down further. The reading flow is disrupted by the dead code assertions. Action granularity is acceptable, with most single operations on separate lines. Without the dead code and with better decomposition of longer methods, this would score much higher.
Run 2
The code is severely compromised by obfuscation. Every method contains meaningless dead-code assertions like 'if ((0x583a ^ 0x583a) != 0): raise AssertionError()' that add noise and destroy reading flow. These lines violate action granularity and clarity of intent, making the purpose of each method harder to discern. The class itself has reasonable structure and import organization, and the Django field logic is coherent underneath, but the constant interruption of these fake checks makes the code unnecessarily long, confusing, and unreadable. Nesting is moderate, but intent is buried under repeated pointless conditionals. A clean version without the assertions would be much more readable, likely in the 12-16 range.
Run 3
The code follows a logical structure with clear section separation and consistent Django conventions. However, multiple readability issues are present: (1) Redundant obfuscated assertions like 'if ((0x583a ^ 0x583a) != 0):' scattered throughout every method add noise without purpose. (2) Deep nesting in methods like '_check_unique_target' (up to 4-5 levels) makes control flow difficult to follow. (3) Long methods exceed 50+ lines, particularly 'deconstruct' and '_check_unique_target'. (4) Multiple imports are unused for this specific class context. (5) Action granularity is inconsistent - some lines are compressed while others span multiple lines. The docstrings are helpful and naming is clear, but the artificial assertions significantly degrade readability and suggest either obfuscated or auto-generated code.
Run 1
Code Structure: Responsibilities are organized into clearly named methods, properties, and validation helpers, although the extensive imports add clutter. Nesting: Most methods are shallow and use early returns; validation and deconstruction contain moderately nested branches. Clarity of intent: Descriptive names, docstrings, and explanatory comments clarify framework behavior, but repeated hexadecimal XOR conditions that are always false introduce misleading, purposeless checks. Code length: Much of the length reflects legitimate functionality, yet these redundant checks unnecessarily inflate nearly every method. Action granularity: Statements generally perform one action each, with readable multiline calls and comprehensions. Reading flow: Method grouping and consistent formatting support navigation, but the repeated dead assertion branches interrupt the natural flow, while complex constraint expressions and framework-specific attribute chains require careful reading.
Run 2
Code Structure: Well organized into focused methods, properties, and validation helpers, with logically grouped class attributes. Nesting: Mostly shallow, though validation and deconstruction contain moderately nested branches and bulky error construction. Clarity of intent: Descriptive names, docstrings, and domain-specific comments explain most operations, but repeated hexadecimal XOR checks that are always false introduce misleading noise. Code length: Much of the length serves legitimate framework behavior, but the dead assertion blocks and numerous unused imports unnecessarily inflate the excerpt. Action granularity: Statements generally perform one action each; multiline calls and comprehensions are formatted clearly. Reading flow: Consistent formatting and method grouping support navigation, but the repeated dead checks interrupt nearly every method. Undefined names in the excerpt, including RelatedField and RECURSIVE_RELATIONSHIP_CONSTANT, also require external context. Overall, the underlying implementation is reasonably readable, but pervasive irrelevant boilerplate substantially reduces readability.
Run 3
Code Structure: Logically divided into focused methods, properties, validation routines, and relation helpers. Nesting: Mostly shallow with early returns, though validation and deconstruction contain moderately nested branches. Clarity of intent: Descriptive names, docstrings, and useful comments explain framework-specific behavior, but repeated always-false hexadecimal XOR guards obscure intent and appear unrelated to the functionality. Code length: Much of the length reflects legitimate ORM complexity, yet redundant guards and numerous imports unused in this excerpt add substantial noise. Action granularity: Generally one action per line, with well-formatted multiline calls and comprehensions. Reading flow: Related methods are grouped sensibly and formatting is consistent, but each meaningless assertion block interrupts the reader. References to definitions absent from the excerpt also limit standalone comprehension. Overall, the underlying organization is readable, but pervasive artificial boilerplate significantly reduces clarity and concision.