Sample
pyint-1f723b92104c-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.214 | 0–1; higher is more readable |
| Mi | 0.353 | 0–1; higher is more readable |
| LLOC | 69 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.639 | 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. | 4151.512 | −137 |
| Source linesThe number of non-empty source lines. | 133 | +53.2 |
| 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.251 | −6.377 |
Intercept 8.87 + feature contributions = -81.307 (log-odds).
Score = sigmoid(-81.307) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 132 | +3.829 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 133 | −3.673 |
| 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. | 132.857 | +1.447 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.065 | +0.312 |
| 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.948 | +0.152 |
Intercept 0.07 + feature contributions = -1.298 (log-odds).
Score = sigmoid(-1.298) = 0.214.
| Score | 0.353 |
|---|
| Score | 69 |
|---|
Run 1
The code is generally well-structured and readable. It follows Django's common patterns, with clear method names and logical separation of concerns. The class is organized into small, focused methods, each handling a single responsibility. Nesting is moderate, with only a few levels of indentation. The intent of each method is clear, and the code length is appropriate. However, some minor improvements could be made, such as reducing the complexity of paginate_queryset and avoiding the multiple assignments to 'queryset' in get_queryset. Overall, the code is easy to follow for developers familiar with Django's class-based views.
Run 2
The code is well-structured with clear separation of concerns, following Django's CBV patterns. Each method has a single responsibility (fetching queryset, pagination, context building). Nesting is minimal and manageable. Variable names are descriptive. However, minor readability issues exist: multiple actions occur on single lines (e.g., chained .get() with 'or', combined exception raising with .format()), and some logic like pagination error handling could be clearer with intermediate variables. Overall the reading flow is natural and consistent with Django conventions.
Run 3
This Django mixin is generally well-structured and readable. It follows a clean, conventional class-based view pattern with consistent method separation and clear naming. The file begins with logical imports, and each method has a single responsibility, contributing to good action granularity. Nesting is mostly flat; the conditional trees in get_queryset and paginate_queryset are manageable, though slightly deep in places. The code is reasonably concise with minimal redundancy. Some minor issues affect readability: the repeated else/raise pattern in get_queryset is a bit cumbersome, and the try/except blocks in paginate_queryset interrupt flowing comprehension. Overall, the intent is clear for developers familiar with Django, but less so for newcomers.
Run 1
Code Structure: Well-organized mixin with configuration attributes followed by focused methods for querying, pagination, and context construction. Nesting: Generally shallow, with modest nesting in queryset selection and page parsing. Clarity of intent: Descriptive method and variable names communicate purpose, although missing docstrings and Django-specific conventions require framework familiarity. Code length: Mostly concise; trivial getter methods support customization, but duplicated context dictionaries and excess blank lines add bulk. Action granularity: Statements generally perform one action per line, and multiline calls improve readability; the pagination tuple return packs several related outputs together. Reading flow: Methods follow a coherent progression from retrieving data to pagination and context assembly. Exception handling is localized and understandable, though reusing 'page' and 'queryset' for different representations slightly complicates tracking values.
Run 2
Code Structure: Well-organized mixin with focused methods separating queryset selection, pagination, and context construction. Nesting: Mostly shallow, with manageable nested conditionals and exception handling. Clarity of intent: Descriptive method and variable names make the purpose clear, although missing docstrings and Django-specific conventions require framework familiarity. Code length: Generally concise; small accessor methods support customization, but duplicated context dictionaries and unnecessary blank lines add some bulk. Action granularity: Statements typically perform one action per line, with readable multiline calls and dictionaries. Reading flow: Methods follow a natural progression from retrieving data to pagination and context assembly. Minor friction comes from reusing 'page' for both input and a page object, and 'queryset' for potentially paginated results.
Run 3
Code Structure: Well-organized mixin with focused methods separating queryset selection, pagination, configuration, and context construction. Nesting: Generally shallow, with limited nested conditionals for ordering and page validation. Clarity of intent: Descriptive method and variable names make responsibilities clear, though missing docstrings and reliance on Django conventions obscure some details, particularly the pagination tuple. Code length: Mostly concise; small configuration getters support customization, but repeated context dictionaries and unnecessary blank lines add bulk. Action granularity: Statements generally perform one action per line, and multiline calls improve readability. Reading flow: Methods follow a natural progression from data retrieval to pagination and context assembly, although helper-method indirection and reuse of page and queryset for different representations require some tracking.