Sample
pyint-bea7fb27e0bf-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.461 | 0–1; higher is more readable |
| Mi | 0.357 | 0–1; higher is more readable |
| LLOC | 79 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.658 | 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. | 4290.036 | −141.571 |
| Source linesThe number of non-empty source lines. | 146 | +58.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.314 | −6.472 |
Intercept 8.87 + feature contributions = -80.773 (log-odds).
Score = sigmoid(-80.773) = 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. | 147 | −4.168 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 132 | +3.829 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 133 | −2.631 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 145.845 | +1.629 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 82.912 | +0.533 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.43 |
| 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.946 | +0.152 |
Intercept 0.07 + feature contributions = -0.157 (log-odds).
Score = sigmoid(-0.157) = 0.461.
| Score | 0.357 |
|---|
| Score | 79 |
|---|
Run 1
The code is generally well-structured and readable, benefiting from clear method separation and descriptive docstrings. However, it has a few areas that reduce clarity. The get_queryset method contains nested conditionals and multiple responsibilities (querying and ordering), which makes it slightly harder to follow. The paginate_queryset method has a try-except with a nested conditional, and the loop-free flow is mostly linear but occasionally dense. Variable naming is clear, and each line tends to represent one action, but some lines combine multiple operations. Overall, it's clear and maintainable, though not as flat or concise as it could be.
Run 2
The code is well-structured and follows Django's established mixin pattern, making it familiar and logical. It is largely flat, with only mild nesting in pagination and queryset checks. Intent is clear through descriptive method names, docstrings, and standard Django conventions. Length is reasonable, though `get_context_data` has some repetition. Action granularity is mostly one action per line, though the pagination page retrieval line is overly dense and reduces readability. Reading flow is natural and organized. Minor deductions: the complex ternary-like page retrieval, repeated context dictionaries, and overloaded `page` variable slightly reduce clarity. Overall, it is highly readable for developers familiar with Django class-based views.
Run 3
The code is highly readable with clear structure, logical organization, and good use of class-based mixin pattern. Each method has a single responsibility and is well-documented with docstrings explaining intent. Nesting is mostly flat, with only 2-3 levels in methods like get_queryset and paginate_queryset, which is acceptable. Intent is clear throughout—method names like get_paginate_orphans and get_allow_empty are self-documenting. Code length is appropriate, though some methods could be slightly more concise. Action granularity is generally one action per line, especially in paginate_queryset where each step (fetching page number, parsing, error handling) occupies its own line. Reading flow is natural—methods are ordered from data access (get_queryset) to pagination to context construction, following a logical progression. Minor deductions: the nested try/except in paginate_queryset adds slight cognitive overhead, and the error message strings are long, but these are Django conventions and not readability issues.
Run 1
Code Structure: Well-organized mixin with focused methods separating queryset selection, ordering, pagination, and context construction. Nesting: Mostly shallow, with modest nested conditionals and straightforward exception handling. Clarity of intent: Descriptive method names, configuration attributes, and docstrings make responsibilities clear; Django-specific conventions and the positional pagination return tuple require some familiarity. Code length: Reasonably concise for its functionality, although context dictionaries repeat several keys and simple accessor methods add length while supporting customization. Action granularity: Statements generally perform one action each, with readable multiline calls and dictionaries; tuple unpacking remains manageable. Reading flow: Methods follow a coherent progression from data retrieval through pagination to context assembly. Minor distractions include unused imports, reuse of 'page' for different types, and an awkwardly worded orphan-pagination docstring.
Run 2
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, and context construction. Nesting: Generally shallow, with modest nesting for configuration and page validation. Clarity of intent: Descriptive method names, configuration attributes, docstrings, and informative exceptions make behavior clear; Django-specific conventions require framework knowledge. Code length: Mostly concise, though numerous simple accessor methods and duplicated context dictionaries add some verbosity. Action granularity: Statements generally perform one action each; tuple unpacking and chained page-source selection remain understandable. Reading flow: Methods follow a logical progression, and consistent formatting supports scanning. Minor drawbacks include unused imports, reuse of the page variable for different types, and an awkwardly worded pagination docstring.
Run 3
Code Structure: Responsibilities are logically separated into focused methods, with configuration attributes grouped clearly. Nesting: Generally shallow; queryset selection and pagination error handling introduce only moderate nesting. Clarity of intent: Descriptive method names, docstrings, and explicit error messages make the purpose clear, although Django-specific conventions and the pagination tuple require some familiarity. Code length: Mostly concise, but trivial accessor methods and repeated context dictionary keys add verbosity. Action granularity: Statements generally perform one action each; tuple unpacking and chained page-source selection remain manageable. Reading flow: Consistent formatting and a natural progression from queryset retrieval through pagination to context construction support easy reading. Minor distractions include unused imports, a grammatically awkward docstring, and reassignment of variables such as page and queryset to different representations.