Sample
pyint-15e77a98ba05-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.876 | 0–1; higher is more readable |
| Mi | 0.598 | 0–1; higher is more readable |
| LLOC | 153 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.398 | 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. | 9152.424 | −302.03 |
| Source linesThe number of non-empty source lines. | 314 | +125.6 |
| 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.342 | −6.513 |
Intercept 8.87 + feature contributions = -174.073 (log-odds).
Score = sigmoid(-174.073) = 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. | 315 | −10.117 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 215 | +6.699 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 313.835 | +3.977 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 89.679 | +0.642 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.431 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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.975 | −0.146 |
Intercept 0.07 + feature contributions = 1.955 (log-odds).
Score = sigmoid(1.955) = 0.876.
| Score | 0.598 |
|---|
| Score | 153 |
|---|
Run 1
The code has generally clear intent, good docstrings, and logical class organization. However, readability is significantly undermined by artificially padded `if not (condition): pass; else: ...` blocks (e.g., in `set`, `list_domains`, `list_paths`, `multiple_domains`, `_find`, `_find_no_duplicates`, `__setstate__`). These add nesting, verbosity, and cognitive overhead without any benefit. The `multiple_domains` method is especially awkward: it appends to `domains` even on the first domain, making the logic harder to follow. Deep nesting in `_find` and `_find_no_duplicates` is unnecessary and hurts flow. Some methods are concise and well-structured (`get_dict`, `__iter__`, `copy`), but the inconsistent use of conditions creates a tangled, disorganized feel. Overall, the code is functional and documented, but unnecessarily long and nested.
Run 2
The code has a clear class structure and docstrings, but readability is severely hampered by convoluted boolean logic using inverted `if not (...): pass else:` patterns throughout (`set`, `list_domains`, `list_paths`, `multiple_domains`, `_find`, `_find_no_duplicates`, `__setstate__`). This is a major anti-pattern that obscures intent and creates unnecessary nesting. Multiple actions are sometimes packed into lines (e.g., walrus operator in `set_cookie`), and methods like `_find_no_duplicates` use non-idiomatic variable naming (`toReturn`) and deeply nested conditionals. The import section appears slightly disorganized with many unused imports. While documentation is thorough, the inconsistent and illogical control flow makes the logic difficult to follow and maintain.
Run 3
The code has a clear overall class structure and generally good docstrings, but readability is severely hampered by pervasive inverted conditional patterns (e.g., `if not (condition): pass else: ...`) throughout methods like `set`, `list_domains`, `list_paths`, `multiple_domains`, `update`, `_find`, `_find_no_duplicates`, and `__setstate__`. This creates unnecessary nesting, breaks natural reading flow, and obscures intent. Several methods also suffer from excessive nesting (e.g., `_find`, `_find_no_duplicates`). While individual actions are mostly one per line, the logical organization is tangled due to these contrarian control structures. Some type hints and the overall structure are positive, but the execution within methods makes the code difficult to follow and maintain.
Run 1
Code Structure: Logically organized into small methods covering mapping operations, cookie lookup, and serialization. Nesting: Most methods are shallow, but lookup methods contain unnecessarily deep conditional chains. Clarity of intent: Descriptive method names, type hints, and docstrings clarify the interface; negated conditions, double negatives, empty pass branches, and the inconsistent toReturn name obscure implementation details. Some documentation does not align clearly with behavior. Code length: Reasonable for the interface provided, but repetitive docstrings and redundant if/pass/else constructs add avoidable length. Action granularity: Generally one action per line; the assignment expression in set_cookie slightly increases cognitive load. Reading flow: Method grouping is natural, but repeatedly inverted conditions force readers to mentally reconstruct straightforward logic, and threading is separated from other standard-library imports. Overall, the class is understandable and well documented, but simplifying conditions and flattening lookup logic would substantially improve readability.
Run 2
1. Code Structure: Methods are logically separated within a cohesive class, though imports are inconsistently grouped. 2. Nesting: Most methods are shallow, but cookie lookup methods contain unnecessarily deep conditional chains. 3. Clarity of intent: Descriptive method names, type hints, and extensive docstrings help, but negated conditions with empty pass branches obscure straightforward logic. Some documentation conflicts with implementation, particularly multiple_domains and __setitem__. 4. Code length: Small methods are generally concise, but repetitive docstrings and redundant if/pass/else constructs add avoidable bulk. 5. Action granularity: Statements mostly perform one action per line; the assignment expression in set_cookie is a minor exception. 6. Reading flow: Method organization and consistent formatting support navigation, but repeated inverted conditions, double negatives, and the inconsistent toReturn name interrupt natural reading.
Run 3
Code Structure: Well organized into focused methods for mapping operations, cookie lookup, and serialization, though imports are inconsistently grouped. Nesting: Most methods are shallow, but lookup methods contain several nested conditionals that could be flattened. Clarity of intent: Descriptive method names, type annotations, and extensive docstrings help; negated conditions, double negatives, empty pass branches, and the vague toReturn variable obscure otherwise simple logic. Some documentation is misleading, notably multiple_domains, which detects repeated domains rather than distinct ones. Code length: Generally reasonable for the interface provided, but repetitive documentation and unnecessary if/pass/else constructs add bulk. Action granularity: Usually one action per line; the assignment expression in set_cookie slightly combines actions but remains understandable. Reading flow: Method grouping is natural, yet repeated inverted conditions interrupt the flow and force readers to mentally reconstruct straightforward checks.