Sample
pyint-acd81d65310c-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.6 | 0–1; higher is more readable |
| Mi | 0.56 | 0–1; higher is more readable |
| LLOC | 47 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.379 | 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. | 2634.481 | −86.938 |
| Source linesThe number of non-empty source lines. | 73 | +29.2 |
| 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.576 | −6.865 |
Intercept 8.87 + feature contributions = -55.732 (log-odds).
Score = sigmoid(-55.732) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 68 | +1.615 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 74 | −1.584 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 68 | −1.14 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.946 | +0.615 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 72.933 | +0.61 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.068 | +0.28 |
| 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.959 | −0.06 |
Intercept 0.07 + feature contributions = 0.405 (log-odds).
Score = sigmoid(0.405) = 0.6.
| Score | 0.56 |
|---|
| Score | 47 |
|---|
Run 1
The code is moderately readable. It has a clear class structure and imports are organized, but there are issues. The random assertions like 'if ((0x83dd ^ 0x83dd) != 0): raise AssertionError()' are confusing and appear to be intentional obfuscation or debugging artifacts. These add noise and reduce clarity. The nesting is shallow, and most methods are short with one action per line, which is good. However, the 'clean' method has multiple return points and conditional branches that make the flow slightly harder to follow. The docstring for the class is helpful, but the overall intent of some checks (like the assertions) is unclear. The code length is reasonable, and the reading flow is mostly logical, but the presence of meaningless checks disrupts it. Action granularity is generally fine. Overall, the code would be more readable without the confusing assertion lines and with slightly better organization of conditional logic.
Run 2
The code follows a generally logical class structure, with clear separation of initialization, cleaning, and change detection. However, readability is significantly harmed by meaningless obfuscation checks like `if ((0x83dd ^ 0x83dd) != 0): raise AssertionError()`, which add noise without purpose. Nesting is moderate: two levels in `__init__` are acceptable, but could be flattened using a conditional expression. Intent is mostly clear—validating an inline foreign key—but the extra assertions obscure it. Length is reasonable, though some lines are long and could be wrapped for clarity. Action granularity is mixed: many lines do one thing, but compound boolean checks are spread across multiple lines unnecessarily. Reading flow is natural in `clean` but disrupted in `__init__` by the fake assertions and nested conditionals. Removing the dead-code guards and simplifying the initial-value logic would improve clarity considerably.
Run 3
The code is generally readable with clear class structure and logical organization. The InlineForeignKeyField class has a clear purpose and well-named methods. However, several issues reduce readability: dead code with meaningless assertions (e.g., `if ((0x83dd ^ 0x83dd) != 0)`) adds confusion and unnecessary length. The `clean` method mixes return paths and comments without clear separation, slightly affecting flow. Import statements are well-organized but lengthy. Nesting is minimal, which is good, and actions are mostly one per line. The `__init__` method has a reasonable flow, though the nested `if` conditions could be flattened slightly for clarity. Overall, the code is functional but contains artifacts that obscure intent and increase cognitive load.
Run 1
Code Structure: The class is logically organized into initialization, validation, and change detection, but numerous unused imports add clutter. Nesting: Mostly shallow, with manageable nested conditionals in initialization and empty-value handling. Clarity of intent: Descriptive method names, a docstring, and comments explain the field's purpose; however, repeated hexadecimal XOR checks are always false and obscure intent with pointless defensive-looking code. Code length: The functional implementation is reasonably concise, but unused imports and unreachable assertion blocks unnecessarily lengthen it. Action granularity: Statements generally perform one action per line, and multiline calls are formatted clearly. Reading flow: Methods follow a natural lifecycle and use early returns effectively, though the repeated dead checks interrupt that flow.
Run 2
Code Structure: The class is logically organized into initialization, validation, and change detection, but many unrelated imports add clutter. Nesting: Mostly shallow, with manageable two-level conditionals. Clarity of intent: Descriptive names, a docstring, and comments explain the field's purpose; however, repeated hexadecimal XOR checks that always evaluate to false introduce confusing dead code. Code length: Core logic is reasonably concise, but unused imports and redundant assertion blocks unnecessarily inflate the snippet. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Method order and validation steps are natural, but the meaningless checks interrupt every method and distract from otherwise straightforward behavior.
Run 3
Code Structure: The class is logically divided into initialization, validation, and change detection, but numerous unused imports add clutter. Nesting: Mostly shallow, with a manageable two-level conditional in initialization and validation. Clarity of intent: Descriptive names, a docstring, and comments explain the parent-instance validation, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless code. Code length: Core methods are concise; unnecessary imports and unreachable assertion blocks inflate the snippet. Action granularity: Each line generally performs one action, and multiline calls are formatted clearly. Reading flow: Method order and early returns support natural reading, but the repeated assertion guards interrupt the meaningful logic.