Sample
pyint-6f1b37811ad5-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.26 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 66 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.397 | 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. | 4811.648 | −158.784 |
| Source linesThe number of non-empty source lines. | 168 | +67.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.635 | −6.953 |
Intercept 8.87 + feature contributions = -89.667 (log-odds).
Score = sigmoid(-89.667) = 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. | 169 | −4.947 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 141 | +4.14 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 141 | −2.815 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 167.951 | +1.938 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 101.929 | +0.84 |
| 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. | 101.959 | −0.653 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.058 | +0.38 |
Intercept 0.07 + feature contributions = -1.048 (log-odds).
Score = sigmoid(-1.048) = 0.26.
| Score | 0.561 |
|---|
| Score | 66 |
|---|
Run 1
The code is a mix of clear parts and confusing obfuscations. The structure is logical with a clean class definition, type annotations, and good docstrings, but the repeated nonsensical 'if ((0x... ^ 0x...) != 0): raise AssertionError()' blocks are highly disruptive. They break reading flow and make intent ambiguous, likely as anti-debugging tricks. Imports are extensive but organized. Nesting is generally flat within methods. Action granularity is mostly one action per line. However, the obfuscated conditions add unnecessary noise, hurt readability, and lower the overall score from what would otherwise be a very readable code (around 18-19).
Run 2
The code has a clear, logical class structure with well-documented parameters and usage examples, which aids readability. Imports are grouped logically. However, readability is severely undermined by the presence of meaningless obfuscated lines like `if ((0xa5dd ^ 0xa5dd) != 0): raise AssertionError()` which serve no purpose and confuse intent. The code is relatively flat and actions are generally one per line, but the lengthy constructor with many parameters and repetitive default assignments adds verbosity. The method `prepare()` is clean, but the overall flow is disrupted by the dead code. Type annotations are helpful, and the naming is clear, but the combination of boilerplate, long import blocks, and injected nonsense reduces clarity and trust, preventing a higher score.
Run 3
The code has clear structure with organized imports, type hints, and a well-documented class. The Request class is logically organized with clear attributes and methods. However, several readability issues reduce the score: the inclusion of dead code blocks like `if ((0xa5dd ^ 0xa5dd) != 0): raise AssertionError()` is confusing and adds unnecessary complexity. The `__init__` method uses multiple assignments per line (e.g., `data = [] if data is None else data`), which slightly reduces action granularity. The import section is long but logically grouped. Overall the code is readable but could be improved by removing dead code and improving line-by-line clarity.
Run 1
1. Code Structure: Imports, documentation, type declarations, and methods are logically organized, although several referenced classes are not defined or imported in the excerpt. 2. Nesting: Mostly flat, with only simple conditionals and one loop. 3. Clarity of intent: Descriptive names, type hints, and detailed documentation clearly communicate request construction and preparation; repeated always-false XOR checks introduce confusing, purposeless noise. 4. Code length: Initialization is straightforward, but extensive imports and redundant assertion blocks make this excerpt longer than necessary. 5. Action granularity: Statements generally perform one action per line, making assignments and preparation arguments easy to inspect. 6. Reading flow: The progression from defaults to hooks, attribute assignment, and request preparation is natural, but unexplained hexadecimal checks interrupt it.
Run 2
Code Structure: The class is logically organized into declarations, initialization, representation, and preparation, although the extensive imports obscure the main code. Nesting: Control flow is shallow, with simple conditionals and one loop. Clarity of intent: Descriptive method names, type annotations, and documentation explain request construction well; unexplained hexadecimal XOR checks that are always false introduce distracting ambiguity. Code length: Most class code is appropriately sized, but redundant assertion blocks and imports unused in this excerpt add unnecessary length. Action granularity: Statements generally perform one action per line, and multiline argument lists are easy to scan. Reading flow: Initialization and preparation follow a natural sequence, but the repeated dead-code checks interrupt it. Referenced classes and mixins absent from the excerpt also require external context.
Run 3
Code Structure: The class is logically organized into initialization, representation, and preparation, though the extensive imports include many names unused in this excerpt. Nesting: Control flow is shallow, with only simple conditionals and a loop. Clarity of intent: Descriptive method names, type annotations, and comprehensive documentation make the request lifecycle clear; repeated always-false XOR checks introduce unexplained noise. Code length: Most initialization and argument forwarding are reasonable, but irrelevant imports and dead assertion branches unnecessarily lengthen the snippet. Action granularity: Statements generally perform one action per line, and multiline signatures and calls are easy to scan. Reading flow: Attribute assignments and preparation arguments follow a consistent sequence, but redundant checks interrupt otherwise natural progression. Referenced classes absent from the excerpt also require external context.