Sample
pyint-1ea4cfdb4061-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.185 | 0–1; higher is more readable |
| Mi | 0.335 | 0–1; higher is more readable |
| LLOC | 108 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs |
| BTTF | 0.432 | 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. | 9829.893 | −324.386 |
| Source linesThe number of non-empty source lines. | 251 | +100.4 |
| 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.322 | −6.483 |
Intercept 8.87 + feature contributions = -221.599 (log-odds).
Score = sigmoid(-221.599) = 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. | 251 | −7.851 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 226 | +7.08 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 226 | −4.765 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 250.966 | +3.098 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.944 | +0.615 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.063 | +0.332 |
| 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. | 87.984 | −0.061 |
Intercept 0.07 + feature contributions = -1.483 (log-odds).
Score = sigmoid(-1.483) = 0.185.
| Score | 0.335 |
|---|
| Score | 108 |
|---|
Run 1
The code exhibits poor readability due to pervasive inverted conditionals like `if not (not obj): pass else: ...`, which are confusing and should be simplified to `if obj is None:`. This pattern recurs in several methods, obscuring logic. The structure is functional but the unnatural control flow and verbose negations disrupt clarity. Nesting is moderate but the conditional inversions create unnecessary complexity. Action granularity is mixed; some sections are clear, but the inverted patterns lead to multiple logical steps per line. The reading flow is disorganized and counterintuitive. While imports and class attributes are well-organized, the core logic suffers from needless convolutions. Overall, the code is hard to follow and maintain.
Run 2
The code has some readable elements like clear variable names, helpful comments explaining non-obvious logic, and organization into logical methods. However, it is severely undermined by pervasive inverted conditional patterns using 'if not (condition): pass else:' constructs throughout. This creates confusing double negatives that obscure the actual logic flow and make the code significantly harder to read. For example, 'if not (user is None): pass else: raise Http404...' should simply be 'if user is None: raise Http404...'. This poor pattern appears in get_fieldsets, get_form, add_view, _add_view, user_change_password, and response_add. Additionally, several methods are overly long, particularly user_change_password which handles multiple responsibilities including permission checking, form validation, password updates, and response construction. The nesting in user_change_password reaches several levels deep within its main branch. While the code follows Django admin conventions and is reasonably organized structurally, the pervasive inverted conditionals and verbose method implementations make it much less readable than it could be.
Run 3
The code suffers from severe readability issues due to inverted conditional patterns throughout. Multiple instances of 'if not (condition): pass else:' create confusing nesting that obscures intent. For example, in get_fieldsets, get_form, add_view, _add_view, user_change_password, and response_add, these inverted conditions force readers to mentally flip boolean logic. The Django admin class structure is otherwise well-organized with clear fieldset definitions and method separation, but the unnatural conditional patterns break reading flow and make the code appear disorganized. The long user_change_password method also mixes multiple concerns (validation, form handling, password updates, context building) without extraction into helper methods. Action granularity is acceptable with one operation per line in most cases. The imports are standard Django patterns and contribute to overall structure. The inverse 'if not' style is likely auto-generated or deliberately obfuscated, drastically reducing clarity.
Run 1
Code Structure: Imports, declarative admin configuration, and distinct methods provide logical organization. Nesting: Most methods are shallow, but password-change processing has several nested branches; redundant if/pass/else patterns add avoidable complexity. Clarity of intent: Descriptive names, framework conventions, and explanatory comments clarify purpose, but double negations and inverted conditions obscure otherwise simple checks. Code length: Configuration and security explanations justify much of the length, while repeated no-op branches unnecessarily inflate it; user_change_password also combines several responsibilities. Action granularity: Statements generally perform one action per line, with consistently formatted multiline expressions. Reading flow: Method boundaries and formatting support navigation, but repeatedly evaluating negated conditions and skipping pass branches interrupts the natural flow. Overall, the code remains understandable, especially to Django developers, but simplifying conditionals and extracting parts of the password-change workflow would substantially improve readability.
Run 2
1. Code Structure: Imports, declarative admin configuration, and focused methods provide logical organization, though the password-change method combines several responsibilities. 2. Nesting: Most methods are shallow, but permission checks and password submission handling introduce moderate nesting; empty pass branches add unnecessary structure. 3. Clarity of intent: Descriptive names, familiar Django APIs, and explanatory comments help, but repeated negations and inverted conditions make straightforward decisions harder to understand. 4. Code length: Much of the length is justified by configuration and security handling, but redundant if/pass/else patterns unnecessarily expand the code. 5. Action granularity: Statements generally perform one action per line, with consistently formatted multiline calls and collections. 6. Reading flow: Configuration followed by lifecycle methods is natural, but repeated no-op branches interrupt the flow and force readers to mentally simplify conditions. Overall, the code is reasonably navigable but significantly less readable than equivalent direct conditionals and guard clauses.
Run 3
Code Structure: Imports, configuration attributes, and focused admin methods are logically organized. Nesting: Mostly moderate, but redundant if/pass/else branches and the password-change workflow add unnecessary nesting. Clarity of intent: Descriptive names, Django conventions, and helpful comments explain the purpose, while double negatives such as 'if not (not obj)' obscure straightforward conditions. Code length: Configuration is appropriately explicit, but repeated no-op branches inflate the code, and user_change_password is relatively long. Action granularity: Statements generally perform one action per line, with readable multiline calls and dictionaries. Reading flow: Method boundaries and formatting support navigation, but inverted conditions and empty pass branches repeatedly interrupt natural control flow. Simplifying conditions and extracting parts of the password-change workflow would substantially improve readability.