Sample
pyint-a8c6cc01cce5-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.445 | 0–1; higher is more readable |
| Mi | 0.345 | 0–1; higher is more readable |
| LLOC | 83 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.498 | 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. | 4491.448 | −148.218 |
| 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.314 | −6.472 |
Intercept 8.87 + feature contributions = -85.819 (log-odds).
Score = sigmoid(-85.819) = 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.857 | +1.685 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 81.371 | +0.508 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.428 |
| 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.934 | +0.152 |
Intercept 0.07 + feature contributions = -0.223 (log-odds).
Score = sigmoid(-0.223) = 0.445.
| Score | 0.345 |
|---|
| Score | 83 |
|---|
Run 1
The code is moderately readable. Structure is logical, with clear separation into small, focused methods; however, a confusing dead-code loop (even_number_count) at the start of get_queryset adds noise. Nesting is mostly flat but has minor two-level conditions in get_queryset and get_context_data. Intent is generally clear due to descriptive method names and docstrings, though the dead loop obscures purpose. Code length is reasonable for a Django mixin. Action granularity is mostly one action per line, but some lines combine multiple operations (e.g., page retrieval and fallback). Reading flow is natural and follows a top-down pattern except for the puzzling loop. Overall, it is readable but would benefit from removing the dead code and simplifying a few dense lines.
Run 2
The code has clear docstrings and readable method names, but suffers from several readability issues. The odd 'even_number_count' loop in get_queryset is confusing dead code that obscures intent. Nesting in paginate_queryset goes three levels deep, reducing readability. Multiple actions are compressed into single lines (e.g., the page variable assignment with chained 'or' operators). The get_queryset method chains multiple operations including validation, QuerySet wrapping, and ordering with conditional type-checking, making the flow hard to follow. Context building repeats structure unnecessarily. Method length varies widely, with some methods concise and others (paginate_queryset) long. The reading flow is disrupted by dead code and multi-purpose lines. While Django conventions are followed and docstrings help, the presence of unexplained dead code, deep nesting, and mixed action granularity significantly hurt readability.
Run 3
The code is generally well-structured with clear method separation and docstrings, but it contains a confusing, unrelated block at the start of get_queryset that counts even numbers. This harms clarity of intent and reading flow. The paginate_queryset method has moderate nesting and multiple actions on one line (reading page from kwargs or request), reducing readability. Some methods like get_ordering or get_paginate_by are concise and clear. The mixin follows Django patterns, but the odd counting loop and combined conditional assignments lower the score. Overall, it's readable for experienced Django developers but has unnecessary complexity and inconsistent nesting.
Run 1
Code Structure: Well-organized mixin with focused methods separating queryset selection, ordering, pagination, and context construction. Nesting: Mostly shallow, with manageable conditional and exception-handling blocks. Clarity of intent: Descriptive names and docstrings explain behavior, but the unused even-number counting loop in get_queryset is unrelated and distracting. Code length: Generally appropriate for configurable framework code, though the counting loop adds unnecessary length and context dictionaries repeat common keys. Action granularity: Statements generally perform one clear action; tuple unpacking and chained page lookup remain readable. Reading flow: Methods follow a natural progression from data retrieval to pagination and context assembly. Consistent formatting supports scanning, although framework-specific conventions and indirect calls require some Django familiarity.
Run 2
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, and context construction. Nesting: Mostly shallow, with manageable conditional and exception branches. Clarity of intent: Descriptive names and docstrings explain behavior, but the unused even-number counting loop in get_queryset is unrelated and confusing. Code length: Generally appropriate, though the irrelevant loop and duplicated context dictionary structure add unnecessary length. Action granularity: Statements generally perform one action per line; tuple unpacking and chained page lookup remain readable. Reading flow: Methods follow a coherent progression, and consistent formatting supports scanning. Django-specific conventions and reuse of page and queryset for different representations introduce minor cognitive overhead.
Run 3
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, and context construction. Nesting: Mostly shallow, with manageable conditional and exception-handling blocks. Clarity of intent: Descriptive names and docstrings explain responsibilities, but the unused even_number_count loop is unrelated to queryset retrieval and distracts from its purpose. Code length: Generally appropriate, although the irrelevant loop and duplicated context dictionary structure add unnecessary length. Action granularity: Statements generally perform one action per line; multiline calls and dictionaries remain easy to scan. Reading flow: Methods follow a coherent progression, and formatting is consistent. Framework-specific attribute access and pagination exception handling require some Django familiarity, but overall the code is readable and maintainable.