Sample
pyint-dcae0cad5854-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.404 | 0–1; higher is more readable |
| Mi | 0.658 | 0–1; higher is more readable |
| LLOC | 79 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 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. | 5747.926 | −189.682 |
| Source linesThe number of non-empty source lines. | 154 | +61.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.426 | −6.64 |
Intercept 8.87 + feature contributions = -125.851 (log-odds).
Score = sigmoid(-125.851) = 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. | 155 | −4.452 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 145 | +4.278 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 145 | −2.906 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 153.795 | +1.74 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.89 | +0.597 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.066 | +0.303 |
| 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. | 86.948 | −0.018 |
Intercept 0.07 + feature contributions = -0.387 (log-odds).
Score = sigmoid(-0.387) = 0.404.
| Score | 0.658 |
|---|
| Score | 79 |
|---|
Run 1
The code is generally readable but contains some awkward patterns that reduce clarity. The structure is logical, with clear class organization and a sensible method order. However, the frequent use of inverted conditionals like `if not (can_add_related is None): pass else: ...` is confusing and unnecessarily verbose—these should be simple `if can_add_related is None:` statements. Nesting is mostly flat, which is good, but the constructor has many assignments packed together without visual separation. Intent is clear thanks to good docstrings and comments, though some logic (like backwards compatibility checks) could be more explicit. The code is moderately concise but could be shorter by replacing the inverted conditionals. Action granularity is mostly one action per line, but multi-line boolean expressions add slight complexity. Reading flow is natural, with properties and methods grouped logically.
Run 2
The code has a clear overall structure with logical class organization, but several readability issues lower its score. The most significant problem is the inverted conditional pattern used throughout (`if not condition: pass else:`), which should be standard positive conditionals like `if condition:`. This pattern is counterintuitive and breaks natural reading flow. The deeply nested multiline `getattr()` call inside the `supported` variable assignment is awkward and hard to parse. Multiple imports are unused (json, settings, ValidationError, URLValidator, smart_urlquote, urlencode, Truncator, get_language, NoReverseMatch, UUIDField), suggesting potential code rot. The `url_params` construction using `"&"`.join with a list of tuples is less clear than using Django's built-in `urlencode` utility (which is imported but unused). Action granularity is mostly appropriate, with one logical operation per line in most cases. The class has a clear responsibility and reasonable method decomposition. However, the pervasive inverted conditionals create unnecessary cognitive friction, and the unused imports indicate poor maintenance.
Run 3
The code is generally well-structured with clear class definition, logical method organization, and good use of properties. However, several factors reduce readability: repeated inverted conditional patterns (e.g., 'if not (x): pass else:' instead of direct conditionals), long method signatures with many parameters, and complex boolean logic in __init__ that requires careful parsing. The get_context method contains mixed levels of abstraction and inline URL parameter construction. Imports are excessive but typical for Django admin code. The code effectively delegates to the wrapped widget, showing clear intent, but the conditional patterns feel awkward and could be simplified. Overall, it's maintainable but requires Django familiarity and careful reading of conditional logic.
Run 1
Code Structure: The class is logically organized into initialization, properties, context construction, and delegation methods. Nesting: Depth is shallow, but repeated negated conditions with empty pass branches and else blocks introduce unnecessary branching. Clarity of intent: Descriptive method names, context keys, and comments explain most behavior; double negation obscures straightforward checks, and AutocompleteMixin is not defined or imported in the snippet. Code length: Mostly appropriate for the wrapper, though redundant conditionals and several unused imports add clutter. Action granularity: Statements generally perform one action per line, and multiline calls and dictionaries are formatted clearly. Reading flow: Methods follow a natural progression, but inverted conditions repeatedly interrupt comprehension. Direct positive checks would substantially improve readability.
Run 2
Code Structure: The class is logically organized into initialization, properties, context construction, and delegation methods. Nesting: Mostly shallow, but repeated inverted if/pass/else branches introduce unnecessary control flow. Clarity of intent: Descriptive method and attribute names, comments, and the docstring communicate the wrapper's purpose; double negation and the unexplained AutocompleteMixin reference reduce clarity. Code length: Delegation methods are concise, while redundant branches and several unused imports add avoidable length. Action granularity: Statements generally perform one action per line, and multiline expressions are formatted cleanly. Reading flow: The overall progression is natural, but empty branches repeatedly interrupt straightforward logic, and the long initializer and context-building method require some tracking of related flags.
Run 3
Code Structure: The class is logically organized into initialization, properties, context generation, and delegation methods. Nesting: Mostly shallow, but repeated inverted conditions with empty pass branches introduce unnecessary control flow. Clarity of intent: Descriptive method names, attributes, and comments communicate the widget wrapper’s purpose; double negation and indirect conditions make some behavior harder to interpret. Code length: Delegation methods are concise, but redundant if/else blocks and several unused imports add avoidable length and clutter. Action granularity: Statements generally perform one action per line, and multiline calls and dictionaries are cleanly formatted. Reading flow: The overall progression is natural, although negative conditions, especially the AutocompleteMixin check, interrupt comprehension. Straightforward positive checks and removal of unused imports would substantially improve readability.