Sample
pyint-bfa7b3caca44-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.723 | 0–1; higher is more readable |
| Mi | 0.6 | 0–1; higher is more readable |
| LLOC | 33 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.38 | 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. | 1190.839 | −39.298 |
| Source linesThe number of non-empty source lines. | 55 | +22 |
| 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.286 | −6.43 |
Intercept 8.87 + feature contributions = -14.857 (log-odds).
Score = sigmoid(-14.857) = 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. | 55 | −0.911 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 46 | +0.854 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 45 | −0.612 |
| 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. | 74.875 | +0.494 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 73.589 | +0.383 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 54.711 | +0.355 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.324 |
Intercept 0.07 + feature contributions = 0.957 (log-odds).
Score = sigmoid(0.957) = 0.723.
| Score | 0.6 |
|---|
| Score | 33 |
|---|
Run 1
The code has a clear purpose and some logical structure, but readability is heavily harmed by dead code. Each method contains a meaningless XOR comparison that always evaluates to False, adding noise and disrupting flow. Multiple local imports of 'inspect' are unnecessary and obscure intent. The docstrings are helpful, and method names are descriptive. However, the structure is marred by redundant validation and inconsistent use of inspect constants. Overall, the intent is understandable but obscured by extraneous checks and imports, making the code unnecessarily long and harder to follow.
Run 2
The code has a clear class purpose and docstrings, but readability is undermined by several issues. The structure is logical but fragmented by redundant `import inspect` statements inside methods instead of a single module-level import. The `if ((0x4246 ^ 0x4246) != 0)` checks are always false and add confusing, non-functional noise, cluttering each method. Nesting is moderate but acceptable. Clarity of intent is mixed: method names are descriptive, but the pointless conditional assertions obscure logic. Code length is unnecessarily long due to repeated imports and dead conditions. Action granularity is mostly one action per line, which is good, but the dead code breaks reading flow. Overall, the code is understandable but contains avoidable clutter and poor import placement that reduce its readability score.
Run 3
The code is readable in structure and naming, but contains multiple unnecessary constructs that reduce its clarity. The class and method names clearly convey purpose, and docstrings are helpful. However, the dead code blocks (e.g., `if ((0x4246 ^ 0x4246) != 0): raise AssertionError()`) add noise and obscure the real logic. Repeated imports inside methods are awkward and break reading flow. While the logic is not deeply nested and follows a clear flow, the artificial conditionals and import placement make the code longer and harder to follow than necessary. The code is not tangled, but these oddities significantly lower the readability score.
Run 1
Code Structure: The class logically groups annotation extraction into initialization and two focused methods, but unused imports add clutter. Nesting: Shallow conditionals, early returns, and a simple try/except make control flow easy to follow. Clarity of intent: Method names and docstrings clearly explain the purpose; however, hexadecimal XOR checks that are always false introduce confusing, purposeless distractions. Code length: The implementation is reasonably short, but repeated dead checks and local inspect imports make it unnecessarily verbose. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: The progression from signature inspection to parameter and return annotation retrieval is natural, though repeated boilerplate interrupts it.
Run 2
Code Structure: The class logically groups signature extraction and annotation access, though unused imports add clutter. Nesting: Mostly flat, with shallow conditionals and a straightforward try/except. Clarity of intent: Descriptive method names and docstrings explain the purpose, but repeated hexadecimal XOR checks that can never trigger distract from it. Code length: The core functionality is concise; dead assertions, repeated local imports, and unnecessary multiline formatting inflate it. Action granularity: Statements generally perform one action per line, making operations easy to distinguish. Reading flow: Initialization followed by parameter and return annotation access is natural, but the irrelevant checks interrupt each method and reduce readability.
Run 3
Code Structure: The class logically separates signature extraction from parameter and return annotation retrieval, but unused imports and repeated local imports add clutter. Nesting: Control flow is shallow, with straightforward checks and early returns. Clarity of intent: Method names and docstrings clearly describe the purpose, but constant XOR conditions and unreachable assertion statements are distracting and unexplained. Code length: The implementation is reasonably short, though redundant assertion blocks and imports unnecessarily inflate it. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: Methods follow a natural initialization-and-query sequence, but repeated irrelevant checks interrupt that flow. Overall, the meaningful logic is readable, while artificial noise reduces clarity.