Sample
pyint-285062d42971-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.005 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 218 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.33 | 0–20; mean of three runs |
| BTTF | 0.302 | 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. | 14725.542 | −485.943 |
| Source linesThe number of non-empty source lines. | 448 | +179.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.488 | −6.731 |
Intercept 8.87 + feature contributions = -304.604 (log-odds).
Score = sigmoid(-304.604) = 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. | 449 | −14.861 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 359 | +11.68 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 359 | −7.817 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 447.941 | +5.852 |
| 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. | 133.969 | −2.009 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.987 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.056 | +0.403 |
Intercept 0.07 + feature contributions = -5.326 (log-odds).
Score = sigmoid(-5.326) = 0.005.
| Score | 0.561 |
|---|
| Score | 218 |
|---|
Run 1
The code is a class with clear methods but suffers from multiple readability issues. Every method contains dead code with XOR self-comparison and AssertionError, which adds noise and obscures intent. Import blocks are lengthy but organized. Methods like prepare_url and prepare_body are long and have deep conditional nesting, making logic hard to follow. Some comments are helpful, but many are redundant or overly verbose. Multiple actions are often packed into single lines, and flow jumps between branches abruptly. Variable naming is generally clear, but type hints add complexity without improving readability. The overall structure is recognizable, but the extraneous assertions and long methods reduce clarity significantly.
Run 2
The code is generally well-structured with clear class and method definitions, good type hints, and descriptive docstrings. The overall flow is logical, with methods separated by responsibility (method, URL, headers, body, auth, cookies, hooks). However, there are several readability issues: the pervasive `if ((0xXXXX ^ 0xXXXX) != 0): raise AssertionError()` pattern is confusing and appears to be dead code or obfuscation, which seriously hurts clarity. The `prepare_url` method is quite long and does multiple things, and `prepare_body` has some deep nesting in the file/iterable handling. Some inline comments are helpful, but the assertion checks add unnecessary noise. The code would benefit from removing the assertion obfuscation and splitting longer methods into smaller, focused helpers.
Run 3
The code is severely impaired by pervasive obfuscation artifacts: every method begins with a meaningless XOR assertion (`if ((0xd441 ^ 0xd441) != 0): raise AssertionError()`), which breaks reading flow and adds noise. The class lacks visible inheritance context, and type annotations are complex. Deep conditional nesting in methods like prepare_body and prepare_url makes the logic hard to follow. Multiple actions are crowded into single lines (e.g., self.url = url; return). Imports are numerous and disorganized. Comments are sparse and do not compensate for the tangled structure. While some docstrings exist, the overall clarity, granularity, and structure are poor, making the code difficult to maintain and understand.
Run 1
Code Structure: Well-organized class with focused preparation methods and an explicit orchestration sequence. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that increase reading effort. Clarity of intent: Descriptive method names, type annotations, and explanatory comments make HTTP preparation behavior clear; repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Generally justified by protocol edge cases, but redundant assertions, extensive imports, and some verbose or irrelevant comments reduce concision. Action granularity: Almost every line performs a single action, making state changes easy to follow. Reading flow: The prepare method provides a natural overview, and individual methods generally progress logically; long type-ignore comments, casts, and repeated dead checks interrupt that flow. Overall, readable and modular, but unnecessary clutter and the complexity of body preparation prevent a higher score.
Run 2
Code Structure: Well organized into focused preparation methods, with a clear coordinating prepare method. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, and explanatory docstrings make HTTP request preparation understandable; repeated always-false hexadecimal XOR checks obscure intent and add irrelevant noise. Code length: Much of the length reflects necessary handling of HTTP edge cases, but redundant assertions, extensive imports, and some verbose or unhelpful comments reduce concision. Action granularity: Generally one operation per line, with sensible separation of validation, transformation, and assignment. Reading flow: The preparation sequence is natural and ordering constraints are documented, but pointless checks interrupt every method, while long type-ignore comments and complex body-handling branches disrupt scanning.
Run 3
Code Structure: Responsibilities are logically separated into focused preparation methods, although prepare_body handles several distinct cases. Nesting: Mostly shallow, but body serialization and streaming introduce moderately deep conditional and exception blocks. Clarity of intent: Descriptive method names, type hints, and explanatory docstrings clarify HTTP processing; repeated always-false hexadecimal XOR assertions add confusing, purposeless noise. Code length: Much complexity is justified by protocol handling, but redundant assertions, extensive imports, and some verbose or irrelevant comments reduce concision. Action granularity: Statements generally perform one action per line, with clear intermediate variables. Reading flow: The prepare method provides a natural processing sequence, and comments explain ordering constraints and edge cases. However, injected assertions interrupt every method, long type-ignore annotations distract, and unavailable mixin definitions make some operations harder to follow in isolation.