Sample
pyint-c27aa3967b8c-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.508 | 0–1; higher is more readable |
| Mi | 0.224 | 0–1; higher is more readable |
| LLOC | 44 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.495 | 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. | 2134.653 | −70.444 |
| Source linesThe number of non-empty source lines. | 108 | +43.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.637 | −6.955 |
Intercept 8.87 + feature contributions = -25.329 (log-odds).
Score = sigmoid(-25.329) = 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. | 109 | −2.823 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 58 | +1.269 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 107.8 | +1.097 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 58 | −0.91 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.039 | +0.563 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 77.514 | +0.446 |
| 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. | 78.972 | +0.32 |
Intercept 0.07 + feature contributions = 0.032 (log-odds).
Score = sigmoid(0.032) = 0.508.
| Score | 0.224 |
|---|
| Score | 44 |
|---|
Run 1
The code shows strong readability overall. Its structure is logical, with clear separation between configuration attributes and methods. Nesting is minimal - only one level in the response method's conditional. Intent is well-documented through detailed docstrings and type hints. Length is appropriate for a JSON provider implementation with necessary documentation. Action granularity is good with one operation per line. Reading flow is natural and method order makes sense. Minor deductions: There are suspicious assertion checks that appear to be artifacts or obfuscation, which disrupt clarity. The class-level attribute with a staticmethod and docstring could be slightly clearer, but overall this is a clean, maintainable implementation following Python best practices.
Run 2
The code is generally well-structured with clear class-level configuration attributes, separate methods for dumps/loads/response, and informative docstrings. Nesting is flat. Intent is clear. However, the presence of dead code 'if ((0x3cec ^ 0x3cec) != 0): raise AssertionError()' in three methods is confusing and destroys reading flow. The response method mixes JSON preparation, formatting, and response creation into one method, which could be split for cleaner action granularity. Overall, it is highly readable but artificially obfuscated by the assertion checks.
Run 3
The code is generally well-structured with clear class organization and helpful docstrings. However, it contains unnecessary dead code (assertions that never trigger), which obscures intent and adds noise. The `response()` method has moderate nesting and slightly dense conditional logic. Overall, the code is quite readable due to good naming, type hints, and documentation, but the redundant checks and some verbose sections reduce clarity and efficiency.
Run 1
Code Structure: Logically organized into configuration attributes and three focused methods, though several imports appear unused and referenced helpers are not shown. Nesting: Shallow, with straightforward conditionals and no complicated control flow. Clarity of intent: Descriptive names, type annotations, and thorough docstrings explain serialization and response formatting well. However, repeated XOR conditions that are always false introduce distracting, unexplained dead code. Code length: Methods are concise, but extensive documentation and redundant assertion blocks increase the reading burden. Action granularity: Statements generally perform one action per line; the final response construction combines serialization and formatting but remains understandable. Reading flow: Configuration followed by serialization, deserialization, and response creation provides a natural progression. The artificial assertion checks interrupt that flow and are the main readability weakness.
Run 2
Code Structure: The class is logically organized into configuration attributes and focused serialization methods, though undefined dependencies and unused imports reduce self-containment. Nesting: Control flow is shallow, with only simple conditionals. Clarity of intent: Descriptive names, type annotations, and detailed docstrings make the JSON provider's purpose clear; repeated hexadecimal XOR checks are meaningless distractions. Code length: Implementation is concise, but extensive documentation and redundant assertion branches increase reading overhead. Action granularity: Each statement generally performs one action, with cleanly separated configuration steps. Reading flow: Methods follow a natural serialization, deserialization, and response sequence, but the opaque checks interrupt otherwise straightforward execution.
Run 3
Code Structure: Logically organized into configuration attributes and focused serialization, deserialization, and response methods. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: Descriptive names, type annotations, and detailed docstrings explain behavior well, but unexplained XOR checks that always evaluate to false introduce distracting ambiguity. Referenced definitions such as JSONProvider and _default are absent from the snippet. Code length: Implementation is concise, although extensive documentation and redundant assertion blocks increase its length. Action granularity: Statements generally perform one action per line, with sensible multiline formatting for the response constructor. Reading flow: Methods follow a natural progression, but dead checks interrupt each method, and apparently unused imports add clutter.