Sample
pyint-39a6a08d2866-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.003 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 224 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.42 | 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. | 14675.611 | −484.295 |
| Source linesThe number of non-empty source lines. | 547 | +218.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.395 | −6.592 |
Intercept 8.87 + feature contributions = -263.217 (log-odds).
Score = sigmoid(-263.217) = 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. | 548 | −18.367 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 416 | +13.652 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 416 | −9.125 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 546.97 | +7.236 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 97.965 | +0.776 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.045 | +0.504 |
| 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. | 97.964 | −0.484 |
Intercept 0.07 + feature contributions = -5.738 (log-odds).
Score = sigmoid(-5.738) = 0.003.
| Score | 0.561 |
|---|
| Score | 224 |
|---|
Run 1
The code shows moderate readability but has significant issues. Structure is logical with clear sections and good documentation, but the pervasive pattern of inverted conditionals ('if not (condition): pass else:') is extremely confusing and breaks natural reading flow. Nesting is generally acceptable in most methods, but iter_content contains a deeply nested generate() function with multiple exception handlers. Intent is clear through comprehensive docstrings and type hints, though the inverted conditionals obscure the actual logic. Length is appropriate for the functionality but some methods like iter_content and iter_lines are overly long. Action granularity is inconsistent — some lines are clean and focused while others attempt multiple operations. The reading flow is severely hampered by the unusual conditional patterns that require mental inversion, making even simple logic like 'if not (chardet is not None)' difficult to follow. The code would benefit substantially from standard conditional formatting.
Run 2
The code shows mixed readability. Import section is well-organized but excessively long, making it hard to scan. Class attributes and __init__ have excellent documentation and clear intent, but the widespread use of inverted conditionals like 'if not (condition): pass else:' throughout methods is confusing and breaks natural reading flow. This pattern appears in iter_content, iter_lines, content, text, json, links, raise_for_status, and close methods, making the code unnecessarily convoluted. The nesting is generally shallow, which is good, but the conditional inversion makes even simple logic hard to follow. Some methods like __getstate__ have particularly confusing constructs ('if not (not self._content_consumed)'). Action granularity is mostly one action per line, but the conditional structure violates natural reading flow. While the code has good documentation and logical organization, the pervasive inverted conditionals significantly reduce clarity and maintainability.
Run 3
The code is organized with clear sections and type hints, but readability suffers from severe structural issues. The most glaring problem is the pervasive use of inverted conditionals like 'if not (condition): pass else:' instead of normal 'if condition:' blocks, which disrupts natural reading flow and obscures intent. Nesting levels are problematic in methods like iter_content and json. Import statements are excessively long and clutter the top of the file. Several methods like __getstate__, __bool__, and __nonzero__ are unnecessarily verbose or redundant. Comments are helpful in some places but cannot compensate for the awkward control flow. The pattern of checking truthiness with explicit 'is False/None' comparisons combined with inverted logic makes even simple operations like content retrieval difficult to follow. While the code is functionally organized, the execution of that organization fails to meet basic readability standards.
Run 1
Code Structure: The class is logically divided into focused methods and properties, though the large import section adds clutter. Nesting: Mostly moderate, but unnecessary else branches and pass blocks deepen several methods; streaming and JSON handling are more complex. Clarity of intent: Descriptive names, type annotations, and documentation explain the API well, but pervasive negated conditions and double negatives obscure straightforward decisions. Code length: Extensive documentation is useful, yet repeated docstrings, redundant parentheses, and no-op branches unnecessarily inflate the code. Action granularity: Statements generally perform one action per line, making individual operations easy to identify. Reading flow: Method boundaries and consistent formatting support navigation, but inverted conditions repeatedly interrupt natural reading, requiring readers to mentally reconstruct simpler positive checks. Overall, the organization is solid, but artificially convoluted control flow substantially reduces readability.
Run 2
Code Structure: Cohesive Response class with logically separated properties and methods, although the broad import list adds clutter. Nesting: Mostly moderate, but nested streaming and JSON error-handling paths require attention; unnecessary else branches increase indentation. Clarity of intent: Descriptive names, type hints, and detailed docstrings help, but pervasive negated conditions, double negatives, and empty pass branches obscure straightforward logic. Code length: Excessive boilerplate, repeated documentation, overload declarations, and redundant conditionals make the class longer than necessary. Action granularity: Generally strong, with one assignment or operation per line and clearly separated exception handlers. Reading flow: Method-level organization is natural, but repeatedly placing the meaningful action in an else branch interrupts scanning. Mixed content-state sentinels and type-ignore annotations also increase interpretation effort. Overall, well-documented organization is undermined by unnecessarily indirect control flow.
Run 3
Code Structure: Methods and properties logically organize response handling, although the extensive import list adds clutter. Nesting: Mostly moderate, but nested generator logic, exception handling, and unnecessary else branches increase depth. Clarity of intent: Descriptive names, type annotations, and detailed docstrings explain the API well; repeated negated conditions and double negatives obscure otherwise simple decisions. Code length: Excessive pass/else patterns, duplicated documentation, and verbose conditionals make the class unnecessarily long. Action granularity: Statements generally perform one action per line, with readable assignments and explicit exception mapping. Reading flow: Method boundaries and comments support navigation, but inverted conditions repeatedly force readers to mentally reconstruct the intended positive checks. Overall, the code remains understandable through strong naming and documentation, yet systematic conditional awkwardness significantly reduces readability.