Sample
pyint-a83c3202e73c-SRC
Unmodified source class
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 | 17 | 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 well-structured with clear separation of concerns across methods, each handling a distinct responsibility. Nesting is moderate—only two to three levels deep—mostly within get_queryset and paginate_queryset, which remains readable. Intent is clear: methods have descriptive names and docstrings, and error messages are specific. Length is appropriate for a Django mixin; no unnecessary verbosity. Action granularity is mostly good, though a few lines combine multiple operations (e.g., page variable assignment with chained `or` in paginate_queryset), slightly reducing clarity. Reading flow is logical, moving from queryset retrieval to pagination to context building. Docstrings are consistently used. Overall, the code is highly readable and maintainable, with minor opportunities to reduce line length or improve variable naming in the pagination method.
Run 2
The code is highly readable and well-structured. It follows Django's established patterns for class-based views, with clear separation of concerns through small, single-purpose methods. Nesting is minimal — the deepest logic appears in paginate_queryset with two try-except blocks, but it remains manageable. Intent is explicit through descriptive method names and comprehensive docstrings. Length is appropriate for the functionality, avoiding unnecessary verbosity. Most lines perform a single action, maintaining clear action granularity. Reading flow is natural, with methods logically ordered from queryset retrieval to context preparation. Minor deductions: get_queryset has slightly complex branching, and paginate_queryset contains multiple logical steps that could be extracted, but overall it's an excellent example of maintainable Django code.
Run 3
The code is highly readable with a clear, logical structure. Each method has a single responsibility and is well-documented with concise docstrings. Nesting is minimal—only two levels in the pagination method—and the flow follows a natural top-down progression from queryset retrieval to pagination to context building. Action granularity is appropriate, with complex operations broken into logical steps. Variable names are descriptive, and error handling is explicit. Minor deductions: the paginate_queryset method combines multiple actions per line (page retrieval and int conversion), and some lines are slightly long, but overall the code maintains high clarity and maintainability.
Run 1
Code Structure: Well-organized mixin with focused methods separating queryset selection, ordering, pagination, and context creation. Nesting: Generally shallow, with manageable nested conditionals and exception handling. Clarity of intent: Descriptive method names, configuration attributes, docstrings, and informative errors make responsibilities clear; framework-specific conventions and the four-element pagination tuple require some familiarity. Code length: Mostly concise, although simple accessor methods add boilerplate and the context dictionaries repeat several keys. Action granularity: Statements generally perform one action per line; tuple unpacking and chained page lookup compactly express related operations. Reading flow: Methods follow a logical progression from obtaining objects to preparing template context, with consistent formatting and spacing. Minor drawbacks include reusing 'page' for different types and an awkwardly worded orphan-pagination docstring.
Run 2
Code Structure: Well-organized mixin with clearly separated methods for queryset retrieval, pagination, configuration, and context construction. Nesting: Generally shallow, with only modest nesting in queryset selection and pagination error handling. Clarity of intent: Descriptive names, useful docstrings, and explicit exception messages make the purpose clear; Django conventions and inherited behavior require some framework knowledge. Code length: Appropriate for the functionality, though repeated context dictionaries and numerous simple configuration getters add verbosity. Action granularity: Most statements perform one action; tuple unpacking and the pagination return tuple are slightly denser but remain understandable. Reading flow: Methods follow a natural progression from retrieving objects to pagination and context assembly. Consistent formatting supports scanning, although reusing page for both an input value and a Page object introduces minor cognitive overhead.
Run 3
Code Structure: Well-organized mixin with focused methods separating queryset selection, ordering, pagination, and context construction. Nesting: Mostly shallow, with modest nested conditionals and exception handling that remain easy to follow. Clarity of intent: Descriptive method names, configuration attributes, and docstrings clearly communicate purpose; Django-specific conventions require some framework knowledge. Code length: Generally concise, although simple accessor methods and duplicated context dictionary fields add verbosity. Action granularity: Statements typically perform one action each; tuple unpacking and the pagination return tuple are compact but understandable. Reading flow: Methods follow a logical progression, and consistent formatting supports scanning. Minor friction comes from reusing 'page' for both input and a page object, implicit framework-provided attributes, and unused imports.