Sample
pyint-a0f6b21ea7d4-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.056 | 0–1; higher is more readable |
| Mi | 0.616 | 0–1; higher is more readable |
| LLOC | 147 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.33 | 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. | 9618.82 | −317.421 |
| Source linesThe number of non-empty source lines. | 338 | +135.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.369 | −6.554 |
Intercept 8.87 + feature contributions = -179.905 (log-odds).
Score = sigmoid(-179.905) = 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. | 339 | −10.967 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 270 | +8.602 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 270 | −5.775 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 337.894 | +4.313 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 92.956 | +0.695 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.045 | +0.5 |
| 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. | 92.944 | −0.272 |
Intercept 0.07 + feature contributions = -2.833 (log-odds).
Score = sigmoid(-2.833) = 0.056.
| Score | 0.616 |
|---|
| Score | 147 |
|---|
Run 1
The code demonstrates poor readability due to consistent use of inverted conditional patterns ('if not condition: pass else: action') throughout, which disrupts natural reading flow and obscures intent. Multiple type annotations and imports are missing (e.g., _t.TimeoutType, _t.VerifyType, _t.CertType), suggesting incomplete code. The resolve_redirects method is excessively long (100+ lines) with many nested conditionals and mixed responsibilities, violating the single-responsibility principle. Action granularity is inconsistent - some logical operations span multiple lines while others are compressed. The code structure is tangled, with related logic scattered across methods without clear separation of concerns. Documentation exists for some methods but doesn't compensate for the awkward control flow. While the core logic is functionally correct, the pattern of 'if not X: pass else: action' is particularly problematic, forcing readers to mentally invert conditions repeatedly. This anti-pattern appears in nearly every conditional block, making the code significantly harder to follow than necessary.
Run 2
The code suffers from poor readability primarily due to inverted conditional logic ('if not condition: pass else: ...'), which inverts natural reading flow and obscures intent. This pattern appears repeatedly throughout, making the code feel unnecessarily verbose and awkward. Nesting is moderate but the inverted conditionals create confusion. Several methods are overly long with multiple responsibilities, reducing clarity. Action granularity is adequate with one action per line, but the conditional patterns undermine this. The structure is logical at the class level but individual methods lack clean flow. Documentation strings are helpful but don't compensate for the convoluted boolean logic. Overall, the code would benefit from refactoring inverted conditions into positive, early-return or direct if statements, which would significantly improve readability.
Run 3
The code is highly unreadable due to pervasive inverted conditional patterns. Almost every `if` statement uses `if not (condition): pass else:` structure, which obscures intent and adds unnecessary nesting. The flow is disorganized and forces readers to mentally invert conditions repeatedly. While the module structure and imports are organized, the logic within methods is tangled. Comments are helpful but cannot compensate for the awkward control flow. Many blocks could be simplified with straightforward positive conditions. The code is longer than necessary due to these patterns. Action granularity is inconsistent, with some lines doing multiple operations. Overall, the code is difficult to follow and maintain despite clear docstrings.
Run 1
Code Structure: The mixin separates redirect handling, authentication, proxies, and method rebuilding into logically named methods, though resolve_redirects handles many responsibilities. Nesting: Generally moderate, but repeated empty if branches with actionable else blocks add unnecessary indentation. Clarity of intent: Descriptive names, type annotations, docstrings, and protocol-specific comments explain behavior well; negated conditions and double negatives make straightforward decisions harder to understand. Code length: Much of the length reflects genuine HTTP complexity, but repetitive if-not/pass/else patterns introduce avoidable verbosity, and the redirect resolver is lengthy. Action granularity: Statements generally perform one action per line, with no dense chains of unrelated operations. Reading flow: Processing follows a coherent redirect lifecycle, but inverted branching repeatedly interrupts natural reading and increases mental effort. Overall, the code is understandable and well documented, yet unnecessarily awkward conditional structure prevents high readability.
Run 2
Code Structure: Responsibilities are logically separated into focused methods, although resolve_redirects combines many processing stages. Nesting: Mostly moderate, but repeated if-not/pass/else constructs add unnecessary branches and indentation. Clarity of intent: Descriptive method names, type annotations, docstrings, and protocol explanations help, while negated conditions and double negatives obscure straightforward decisions. Code length: Much of the length reflects legitimate HTTP complexity, but empty pass branches and some verbose comments inflate it unnecessarily. Action granularity: Statements generally perform one action per line, making individual operations easy to identify. Reading flow: Redirect processing follows a coherent sequence, but inverted checks repeatedly interrupt natural reading, and the long redirect loop requires tracking substantial mutable state. Overall, solid organization and documentation are undermined by unnecessarily awkward conditional style.
Run 3
Code Structure: Responsibilities are logically separated into well-named methods, but resolve_redirects combines many processing stages in one long routine. Nesting: Generally moderate, though repeated empty if branches followed by else blocks add unnecessary indentation. Clarity of intent: Descriptive names, type annotations, docstrings, and protocol-specific comments clarify behavior; negated and double-negated conditions obscure otherwise simple decisions. Code length: Much complexity is justified by redirect handling, but repetitive pass branches and verbose condition formatting unnecessarily expand the code. Action granularity: Most lines perform one action, and intermediate variables make transformations easy to inspect. Reading flow: Redirect processing follows a coherent sequence, but inverted conditions repeatedly interrupt natural reading and require mental reversal. Overall, the code is understandable with effort, yet substantially less readable than equivalent straightforward conditionals and smaller helper methods.