Sample
pyint-676d71ae47d8-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.85 | 0–1; higher is more readable |
| Mi | 0.519 | 0–1; higher is more readable |
| LLOC | 25 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs |
| BTTF | 0.466 | 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. | 1351.603 | −44.603 |
| Source linesThe number of non-empty source lines. | 48 | +19.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.582 | −6.873 |
Intercept 8.87 + feature contributions = -23.405 (log-odds).
Score = sigmoid(-23.405) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 45 | +0.819 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 49 | −0.699 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.918 | +0.598 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.065 | +0.308 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 47.864 | +0.259 |
| 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.98 | −0.019 |
Intercept 0.07 + feature contributions = 1.735 (log-odds).
Score = sigmoid(1.735) = 0.85.
| Score | 0.519 |
|---|
| Score | 25 |
|---|
Run 1
The code is moderately readable but has several issues. The _combine method uses awkward double-negative conditionals ('if not (not isinstance...)') with empty pass branches, making the logic convoluted and hard to follow. The nesting is shallow, which is good, but the intent behind the type-checking pattern is unnecessarily obscured. Method names like __or__, __ror__, __and__, and __rand__ are clear for operator overloading, but the inverted boolean checks hurt clarity. The code length is reasonable and action granularity is mostly one action per line, but reading flow suffers from the unnatural conditional structure. The imports and class organization are logical. Overall, simplifying the conditionals to positive checks (e.g., 'if not isinstance...: raise TypeError') would significantly improve readability.
Run 2
The code has a clear purpose and uses logical Django patterns, but several stylistic choices hurt readability. The `_combine` method uses awkward inverted conditionals (`if not (...)`) with empty `pass` blocks and `else` branches, which obscures intent and adds unnecessary nesting. The `reversed` parameter is misleadingly named (it shadows Python's built-in `reversed()`), and the logic for it could be simplified. The class methods are concise and follow consistent patterns, and the overall structure is flat and organized. However, the unnatural control flow in `_combine` disrupts reading flow and makes the code harder to follow than necessary. Positive aspects include one action per line and clear separation of logical operators. The code length is acceptable but could be reduced by simplifying the validation and branching logic. The comments help explain the rationale for using operator overloading, which aids clarity. Overall, the code is functional but would benefit from cleaner conditional expressions and better parameter naming.
Run 3
The code is relatively flat and clear in intent, but has several readability problems. The most significant issue is the awkward `if not (...): pass else: raise TypeError` pattern, which inverts normal conditional logic and forces readers to mentally negate conditions. This appears in `_combine` twice, making the flow feel backwards. Similarly, `if not (reversed): pass else: return ...` is more confusing than a simple `if reversed:` check. Type checking via `not (not isinstance(...))` is unnecessarily convoluted. The class structure is logical and the overall organization is sound, with bitwise operators mapped cleanly to `_combine`. Action granularity is reasonable, but the conditional structure hurts reading flow. Code length is acceptable for what it does. The docstring explaining operator overloading is helpful. With cleaner conditionals and direct boolean logic, this would be significantly more readable.
Run 1
Code Structure: The mixin groups combination logic and operator overloads logically, though several imports are unused in this excerpt. Nesting: Shallow overall, but unnecessary if/pass/else branches add visual clutter. Clarity of intent: Operator methods and constants clearly express logical combination; the double negative in the isinstance check and negated reversed condition obscure otherwise simple decisions. Code length: Compact, but redundant pass statements and branches make _combine longer than necessary. Action granularity: Statements generally perform one action per line, with readable multiline imports and error construction. Reading flow: Consistent overload patterns and the explanatory comment support scanning, while inverted conditions interrupt the natural progression of validation, operand ordering, and construction.
Run 2
Code Structure: The class is logically organized, with shared combination logic followed by operator overloads, but numerous unused imports add clutter. Nesting: Nesting is shallow, although pass/else branches unnecessarily complicate simple conditions. Clarity of intent: Class names, constants, and the explanatory comment clarify logical combination, but the double negation in the type check obscures intent. The parameter name reversed also shadows a built-in. Code length: Operator methods are concise, while redundant conditions and pass statements make _combine longer than necessary. Action granularity: Each line generally performs one action, and multiline formatting is readable. Reading flow: The operator methods follow a consistent pattern, but negated conditions and empty branches interrupt the natural flow; direct validation and a straightforward reversed check would improve readability.
Run 3
Code Structure: The class logically groups combination logic and operator overloads, although many imports are unused in this snippet. Nesting: Depth is low, but redundant if/pass/else branches complicate otherwise simple checks. Clarity of intent: Operator methods and the explanatory comment communicate logical combination clearly; however, the double negation in the type check obscures intent, and naming a parameter 'reversed' shadows a built-in. Code length: Short overall, but unnecessary pass statements and inverted conditions add avoidable lines. Action granularity: Each line generally performs a single action, and the operator methods delegate cleanly. Reading flow: Method ordering and consistent overload implementations are natural, but readers must mentally simplify the conditions before understanding the validation and operand ordering.