Sample
pyint-f46b9b298fda-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.446 | 0–1; higher is more readable |
| Mi | 0.348 | 0–1; higher is more readable |
| LLOC | 81 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.541 | 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. | 4423.662 | −145.981 |
| Source linesThe number of non-empty source lines. | 150 | +60 |
| 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.3 | −6.45 |
Intercept 8.87 + feature contributions = -83.561 (log-odds).
Score = sigmoid(-83.561) = 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. | 151 | −4.31 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 136 | +3.967 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 137 | −2.723 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 149.833 | +1.685 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 82.364 | +0.524 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.419 |
| 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. | 82.947 | +0.152 |
Intercept 0.07 + feature contributions = -0.216 (log-odds).
Score = sigmoid(-0.216) = 0.446.
| Score | 0.348 |
|---|
| Score | 81 |
|---|
Run 1
The code has solid docstrings and clear class attributes, but its readability is undermined by several issues. The structure is mostly logical, yet methods like get_queryset and paginate_queryset are convoluted. Nesting is problematic: the `if not (ordering): pass` and `if not (page_size):` patterns create unnecessary branches and inverted logic, making the flow harder to follow. Intent is generally clear but obscured by odd constructs such as `if not (page == "last")` and the awkward `if not (context_object_name is not None): pass`. Code length is reasonable, though some expressions could be more concise. Action granularity is mixed; most lines perform one action, but some conditionals pack too much logic. Reading flow suffers from these inverted conditions and pass statements, forcing readers to mentally invert the logic. Replacing these with early returns, positive conditionals, and direct else handling would significantly improve readability.
Run 2
The code is generally well-structured and readable, with clear docstrings and class attributes. However, it contains several stylistic inconsistencies that reduce readability. The `if not (ordering): pass else:` pattern in `get_queryset` is unnecessarily awkward compared to a simple `if ordering:` check. Similarly, `if not (page_size):` and `if not (context_object_name is not None): pass else:` patterns add cognitive overhead. The `paginate_queryset` method handles multiple concerns (parameter extraction, type conversion, error handling) with moderate nesting and exception flow that could be clearer. While the code is concise overall and actions are generally well-separated, the inconsistent conditional style and some convoluted boolean expressions make the intent harder to follow than necessary. The reading flow is mostly natural, but these unusual patterns interrupt it.
Run 3
The code is generally well-structured with clear method separation, docstrings, and consistent naming. The main readability issues are unnecessary 'if not (condition): pass else:' constructs in get_queryset, paginate_queryset, and get_context_data, which add noise and obscure intent. These could be simplified to flat 'if condition:' blocks. The paginate_queryset method has moderate nesting (two try/except blocks plus nested conditionals), but remains understandable. Action granularity is mostly one-per-line, though dictionary formatting in context creation is verbose. Import order and class-level attributes are clean. Overall the code is readable and follows Django conventions, but the awkward conditional patterns prevent a higher score.
Run 1
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, configuration, and context construction. Nesting: Generally shallow, although unnecessary else branches and pass statements add avoidable complexity. Clarity of intent: Descriptive method names, meaningful variables, docstrings, and informative exceptions make responsibilities clear; negated conditions such as 'if not (context_object_name is not None)' are harder to parse. Code length: Mostly appropriate for an extensible Django mixin, but duplicated context dictionaries and redundant conditionals introduce verbosity. Action granularity: Statements generally perform one action each, with multiline calls and dictionaries formatted clearly. Reading flow: Methods follow a coherent progression and use consistent formatting, though inverted checks and no-op branches interrupt otherwise natural control flow.
Run 2
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, configuration, and context construction. Nesting: Mostly shallow, although unnecessary pass/else branches introduce avoidable indentation. Clarity of intent: Descriptive method and variable names, docstrings, and informative exceptions make the purpose clear; inverted conditions such as 'if not (context_object_name is not None)' require extra mental effort. Code length: Generally appropriate for an extensible framework component, but redundant branches and repeated context dictionaries add verbosity. Action granularity: Statements generally perform one action per line, with readable formatting for longer calls and dictionaries. Reading flow: Methods follow natural processing sequences, but negative conditions, redundant parentheses, and reuse of 'page' for different types slightly disrupt comprehension.
Run 3
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, configuration, and context construction. Nesting: Generally shallow, but unnecessary pass/else branches and negated conditions add avoidable nesting. Clarity of intent: Descriptive names, docstrings, and informative exceptions make the purpose clear; expressions such as 'if not (context_object_name is not None)' obscure simple checks. Code length: Mostly appropriate for extensible framework code, although repeated context dictionaries and redundant branches add verbosity. Action granularity: Statements generally perform one action each, with multiline calls formatted cleanly; tuple unpacking remains readable. Reading flow: Methods follow a coherent progression, and formatting is consistent. However, inverted conditions, redundant parentheses, and reusing 'page' for both an input value and a page object slightly interrupt comprehension.