Sample
pyint-c6323bbcfbe1-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.436 | 0–1; higher is more readable |
| Mi | 0.444 | 0–1; higher is more readable |
| LLOC | 55 | 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.473 | 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. | 2930.298 | −96.7 |
| Source linesThe number of non-empty source lines. | 127 | +50.8 |
| 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.456 | −6.683 |
Intercept 8.87 + feature contributions = -43.713 (log-odds).
Score = sigmoid(-43.713) = 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. | 128 | −3.496 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 86 | +2.238 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 86 | −1.553 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 126.89 | +1.364 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 89.945 | +0.647 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.033 | +0.618 |
| 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. | 89.977 | −0.146 |
Intercept 0.07 + feature contributions = -0.258 (log-odds).
Score = sigmoid(-0.258) = 0.436.
| Score | 0.444 |
|---|
| Score | 55 |
|---|
Run 1
The code has clear docstrings and follows a logical middleware structure, which aids understanding. However, readability is significantly harmed by unnatural 'if not (...): pass else:' patterns instead of standard positive conditionals. This inverts logic and forces the reader to work backwards. Some methods have moderate nesting and multiple operations per conditional block, reducing action granularity. The code is reasonably concise but could be shorter with standard conditional form. Reading flow is disrupted by the negated structures and redundant 'pass' statements.
Run 2
The code demonstrates some good practices, like clear docstrings and method separation, but its readability is significantly hampered by unusual `if not (...) else:` patterns used in place of straightforward `if` statements. This inverts the natural control flow and adds unnecessary nesting. Several helper imports (re, urlsplit, mail_managers, mailers) are unused, creating confusion about the module's actual dependencies. The 'action granularity' is generally fine, but the inverted conditionals make the code longer and harder to scan. The `should_redirect_with_slash` method uses a return-inside-if with a fallback return outside, which is clear, but other methods force the reader to mentally invert conditions. Overall, the structure is logical but the stylistic choice to avoid negative conditions backfires, reducing clarity and reading flow.
Run 3
The code uses a highly unidiomatic pattern of inverted conditionals (if not condition: pass else: action) throughout every method, making the logic hard to follow. While the code is well-documented with clear docstrings, the actual implementation obscures intent by forcing readers to mentally invert every condition. Nesting is minimal, and action granularity is reasonable, but the repetitive `if not...pass...else` structure makes the code unnecessarily verbose and disrupts natural reading flow. The top-level organization is clear, and individual operations are understandable, but the pervasive anti-pattern of inverted branching significantly reduces readability. Standard `if condition:` statements would dramatically improve clarity. The imports are unused in the shown snippet, which adds minor clutter. Overall, the code demonstrates clear intent in documentation but poor execution in the actual control flow.
Run 1
Code Structure: Well organized into focused middleware methods, with shared redirect logic extracted into helpers. Nesting: Moderate nesting becomes unnecessarily deeper through repeated negated conditions followed by pass and else branches. Clarity of intent: Descriptive method names, docstrings, and comments explain behavior well, but double negatives obscure otherwise straightforward checks. Code length: Mostly proportionate to its responsibilities, although empty branches and unused imports add clutter. Action granularity: Statements generally perform one action per line; multiline expressions and the error message are formatted clearly. Reading flow: Request handling, redirect decisions, path construction, and response processing follow a logical sequence, but the inverted conditional style repeatedly interrupts natural reading. Direct positive conditions or early returns would substantially improve readability.
Run 2
Code Structure: Well-organized middleware class with focused methods separating request checks, redirect decisions, path construction, and response handling. Nesting: Moderate nesting becomes unnecessarily deeper through repeated inverted conditions and empty pass branches. Clarity of intent: Descriptive method names, docstrings, and comments explain behavior clearly, but double negatives make conditions harder to interpret. Code length: Mostly reasonable, though redundant if/pass/else patterns and unused imports add clutter. Action granularity: Statements generally perform one action per line, with appropriately formatted multiline expressions. Reading flow: Methods follow a logical request-to-response progression, but repeatedly placing the meaningful operation in an else branch interrupts natural reading. Direct positive conditions and early returns would substantially improve readability.
Run 3
Code Structure: Well-organized middleware class with focused methods separating request checks, slash handling, and response processing. Nesting: Moderate nesting, particularly in slash validation; repeated inverted conditions with empty pass branches add unnecessary indentation. Clarity of intent: Descriptive method names, docstrings, and comments explain behavior well, but double negatives obscure otherwise straightforward conditions. Code length: Mostly justified, although redundant pass/else constructs and unused imports add clutter. Action granularity: Statements generally perform one action per line, with readable formatting for longer expressions and error messages. Reading flow: Methods follow a natural request-to-response sequence, but repeated negative checks interrupt the flow and force readers to mentally invert conditions. Direct positive conditions and a few guard clauses would substantially improve readability.