Sample
pyint-39bfb32c9106-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.544 | 0–1; higher is more readable |
| Mi | 0.508 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs |
| BTTF | 0.524 | 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. | 2152.36 | −71.028 |
| Source linesThe number of non-empty source lines. | 91 | +36.4 |
| 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.664 | −6.996 |
Intercept 8.87 + feature contributions = -32.754 (log-odds).
Score = sigmoid(-32.754) = 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. | 92 | −2.221 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 77 | +1.926 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 77 | −1.346 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 90.938 | +0.861 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 94.924 | +0.727 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.044 | +0.515 |
| 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. | 94.946 | −0.356 |
Intercept 0.07 + feature contributions = 0.176 (log-odds).
Score = sigmoid(0.176) = 0.544.
| Score | 0.508 |
|---|
| Score | 39 |
|---|
Run 1
The code has a reasonable import organization and uses type hints, which helps clarity. However, it suffers from several readability issues: dead code blocks with meaningless XOR checks and AssertionError raise statements clutter every method, creating noise and hiding the actual logic. The import of 'socket' with a noqa comment and unused imports (e.g., warnings, typing) add confusion. While the send() method's docstring is thorough, the method body is just a NotImplementedError, making it hard to judge real structure. The class name 'BaseAdapter' is clear, but the presence of super().__init__() in a class with no parent beyond object is unnecessary. Overall, the code is hard to follow due to these redundancies, despite a basic logical order and flat nesting.
Run 2
The code has clear structure with well-organized imports and a simple class hierarchy, but several issues reduce readability. Meaningless dead code (if ((0xdbe4 ^ 0xdbe4) != 0): raise AssertionError()) appears repeatedly, confusing readers and masking intent. The imports are cleanly grouped and the type hints are good, but some are unused (socket, typing, Any, TimeoutSauce). The BaseAdapter class is minimal and readable, though the send method's docstring is quite verbose. Nesting is flat and action granularity is reasonable. The reading flow is interrupted by the bizarre conditional assertions that always evaluate to false. Overall, the code has a solid foundation but the dead code and unused imports significantly diminish clarity.
Run 3
The code is well-structured with clear section separation for imports, a single class, and logically ordered methods. Nesting is flat, with no deep conditional blocks. Intent is clear throughout, aided by detailed docstrings and descriptive parameter names. Length is reasonable for an abstract base class, though the import block is extensive but appropriate. Action granularity is mostly one action per line, except for the multi-line import statement. Reading flow is natural, following standard Python conventions. The inclusion of unreachable assertion checks like `if ((0xdbe4 ^ 0xdbe4) != 0): raise AssertionError()` is confusing and detracts from clarity. Type hints improve readability. Minor issues: some imports like `socket` are unused, and the `# noqa: F401` comment suggests lint suppression without context. Overall, the code is highly readable but slightly marred by the odd assertions and import organization.
Run 1
Code Structure: The base adapter and its methods are logically organized, but the large import block is mostly unused in this snippet. Nesting: Methods are shallow, although pointless conditional checks add unnecessary branching. Clarity of intent: Method names, type annotations, and docstrings clearly describe the interface; however, PreparedRequest and _t are undefined in the shown code, and hexadecimal XOR assertions obscure otherwise simple implementations. Code length: Imports, verbose documentation, and redundant assertions make a small interface unnecessarily long. Action granularity: Statements generally perform one action per line, making individual operations easy to scan. Reading flow: The progression from imports to initialization, sending, and cleanup is natural, but repeated always-false checks interrupt that flow.
Run 2
Code Structure: Imports and the adapter interface are logically organized, but numerous imports unrelated to the shown class create clutter. Nesting: Methods remain shallow, with only single-level conditionals. Clarity of intent: Method names, signatures, and docstrings clearly describe the transport interface, but unexplained hexadecimal XOR checks obscure intent; PreparedRequest and _t are also undefined in the snippet. Code length: The small interface is disproportionately long due to imports, extensive documentation, and redundant assertion branches. Action granularity: Each line generally performs one action, making individual statements easy to scan. Reading flow: The class follows a natural initialization, send, and close sequence, but repeated always-false checks interrupt that flow and distract from the actual behavior.
Run 3
Code Structure: Imports and a small adapter class are logically organized, but many imports are unrelated to the displayed implementation. Nesting: Methods are shallow, though redundant conditional blocks add needless nesting. Clarity of intent: Method names, signatures, and docstrings clearly describe the adapter interface; unexplained hexadecimal XOR checks obscure intent, and PreparedRequest and _t are not defined in the snippet. Code length: The actual interface is concise, but extensive imports and always-false assertions inflate it unnecessarily. Action granularity: Statements generally perform one action per line, with no compressed multi-action expressions. Reading flow: The class progresses naturally from initialization to sending and cleanup, but repeated meaningless guards interrupt otherwise straightforward methods.