Sample
pyint-8f194d046c3a-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.448 | 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.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.537 | 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.319 | −6.479 |
Intercept 8.87 + feature contributions = -80.78 (log-odds).
Score = sigmoid(-80.78) = 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.779 | +1.628 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 84.905 | +0.565 |
| 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. | 84.946 | +0.067 |
Intercept 0.07 + feature contributions = -0.21 (log-odds).
Score = sigmoid(-0.21) = 0.448.
| Score | 0.357 |
|---|
| Score | 79 |
|---|
Run 1
This Django mixin is well-structured and readable. The class has a clear single responsibility and follows Django's established CBV patterns. Methods are concise, focused, and logically organized with descriptive names. Flat, non-nested code in most methods keeps the reading flow natural. The paginate_queryset method has some indentation due to try/except blocks but remains manageable. Hex values (0x0) are unusual and slightly obscure intent; decimal 0 would be clearer. The get_context_data method has moderate complexity but maintains clarity through consistent variable naming. Documentation strings and comments provide useful context. Overall, the code is accessible to experienced Django developers, though beginners may need familiarity with Django conventions to fully grasp all patterns.
Run 2
This Django mixin demonstrates good readability through clear docstrings, logical method organization, and appropriate use of guard clauses. The code structure is modular, with each method handling a distinct responsibility (queryset retrieval, pagination, context naming). Nesting is generally shallow except in get_queryset and paginate_queryset, where two-level conditionals are manageable. Intent is well-documented through method names and docstrings, though the pagination error handling flow could benefit from extracting the page number parsing into a helper method. Notably, the code uses hexadecimal literals (0x0, 0x1) which is unconventional for Python and slightly reduces readability compared to standard decimal notation. While the mixin contains many methods, each is appropriately concise. Action granularity is good with one operation per line, and the reading flow follows a natural progression from queryset to pagination to context. Deductions come from hex literals, the ternary-like page assignment line, and paginate_queryset's multiple concerns of parsing, validating, and paginating.
Run 3
The code is well-structured and highly readable, typical of Django's source quality. Methods are logically organized with clear responsibilities and descriptive names. Nesting is minimal, with most methods flat and easy to follow. Intent is clear through docstrings and meaningful variable names. The code is concise without being terse, and each line primarily performs one action or closely related operations. Reading flow is natural, with helper methods (get_ordering, get_paginator, get_paginate_orphans, etc.) defined before their use in get_queryset and get_context_data. Slight deductions for the use of numeric literals like 0x0 instead of 0 and 0x1 instead of 1, which adds minor ambiguity without benefit, and the long error message string construction in get_queryset. The paginate_queryset method has slightly more branching but remains clear. Overall, this is excellent production-quality code.
Run 1
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, configuration, and context construction. Nesting: Mostly shallow, with modest nested conditionals and exception handling that remain easy to follow. Clarity of intent: Descriptive names, docstrings, and informative errors clearly communicate purpose; hexadecimal literals for ordinary defaults and positional pagination return values slightly reduce clarity. Code length: Appropriate for the functionality, though repeated context dictionary fields and numerous simple getters add some verbosity, largely justified by extensibility. Action granularity: Statements generally perform one action each, with readable multiline calls and dictionaries; tuple unpacking remains understandable. Reading flow: Methods progress naturally from retrieving objects to pagination and context assembly. Django-specific conventions and implicit instance attributes require framework familiarity but do not substantially obscure the logic.
Run 2
Code Structure: Well-organized mixin with focused methods separating queryset selection, pagination, and context construction. Nesting: Generally shallow, with manageable conditional and exception-handling blocks. Clarity of intent: Descriptive method names, configuration attributes, and docstrings explain behavior well; hexadecimal constants for ordinary zero and one are unnecessarily distracting. Code length: Appropriate for the functionality, although repeated context dictionaries and trivial accessor methods add some verbosity, largely justified by extensibility. Action granularity: Most lines perform one clear operation; chained page-source selection and tuple unpacking slightly increase cognitive load. Reading flow: Methods follow a natural progression from data retrieval through pagination to context preparation. Framework-specific conventions, reassignment of page and queryset variables, and minor docstring awkwardness modestly reduce accessibility.
Run 3
Code Structure: Well-organized mixin with focused methods separating queryset retrieval, pagination, and context construction. Nesting: Mostly shallow, with manageable conditional branches and exception handling. Clarity of intent: Descriptive names and docstrings explain responsibilities; hexadecimal literals for ordinary counts unnecessarily obscure meaning, and reusing 'page' for different types slightly reduces clarity. Code length: Appropriate overall, though repeated context dictionaries and simple accessor methods add verbosity. Action granularity: Statements generally perform one action each; tuple unpacking remains readable. Reading flow: Consistent formatting and a natural progression from data retrieval to pagination and context assembly make the code easy to follow. Framework-specific attributes and implicit instance state require some Django familiarity.