Sample
pyint-616ceda7294f-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.43 | 0–1; higher is more readable |
| Mi | 0.463 | 0–1; higher is more readable |
| LLOC | 74 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.407 | 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. | 5514.733 | −181.986 |
| Source linesThe number of non-empty source lines. | 144 | +57.6 |
| 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.464 | −6.695 |
Intercept 8.87 + feature contributions = -122.211 (log-odds).
Score = sigmoid(-122.211) = 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. | 145 | −4.098 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 135 | +3.932 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 135 | −2.677 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 143.795 | +1.6 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.938 | +0.598 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.065 | +0.31 |
| 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. | 86.979 | −0.019 |
Intercept 0.07 + feature contributions = -0.283 (log-odds).
Score = sigmoid(-0.283) = 0.43.
| Score | 0.463 |
|---|
| Score | 74 |
|---|
Run 1
The code is highly readable with clear logical organization and structure. It uses a single class with well-named methods and maintains flat nesting through guard-style checks and early returns. Intent is clear from method names and inline comments that explain non-obvious decisions (e.g., backwards compatibility, cascading deletion UX). Code length is appropriate; each method is concise and focused. Action granularity is generally one action per line, though some lines are slightly denser (e.g., boolean assignments). Reading flow is natural—constructor initializes state, properties expose widget behavior, and get_context builds a template context logically. Minor deductions for a few moderately complex expressions and the `url_params` generator that could be slightly more explicit, but overall readability is strong.
Run 2
The code is generally well-structured with clear separation of concerns, logical grouping of imports, and a single class with focused methods. The __init__ method, while containing several conditional assignments, remains readable due to descriptive variable names and comments where needed. However, some areas could be improved: the get_context method has a moderately complex setup with several related attributes being extracted before use, and the URL parameter construction using an awkward generator expression could be clearer. The nesting is mostly flat, and action granularity is appropriate with one primary operation per line. The reading flow is natural, progressing logically from initialization through properties to the context-building logic. Overall, the code is maintainable and comprehensible, with minor opportunities for simplification in the URL parameter generation and context assembly.
Run 3
The code is generally well-structured with clear separation of methods, minimal nesting, and an explicit purpose (Django admin widget wrapper). It follows conventions like one action per line and logical grouping. However, readability is slightly reduced by the long `__init__` method doing multiple things, reliance on `rel` attributes without clear inline context, and some domain-specific complexity (e.g., URL parameter construction) that could benefit from helper methods or comments. Overall, it is concise but not excessively so, and the flow is natural for Django developers.
Run 1
Code Structure: Well-organized class with focused methods, grouped properties, and clear separation of initialization, context construction, and widget delegation. Nesting: Shallow conditionals and no deeply nested control flow make execution easy to follow. Clarity of intent: Descriptive method names, permission flags, and explanatory comments communicate purpose; abbreviated names such as rel and info, framework-specific internals, and the undefined-in-snippet AutocompleteMixin require external knowledge. Code length: Mostly concise, though several unused imports add clutter and get_context is comparatively long. Action granularity: Statements generally perform one action per line, with readable multiline expressions and dictionary construction. Reading flow: Natural progression from setup to properties, URL generation, rendering context, and delegation; the local import and mixed URL-formatting styles introduce minor interruptions.
Run 2
Code Structure: Well-organized class with distinct initialization, delegation, URL generation, and context-building methods. Nesting: Shallow conditionals and no deeply nested control flow make it easy to follow. Clarity of intent: Descriptive method names, permission flags, and explanatory comments communicate purpose, though abbreviated names such as rel and info and Django-specific conventions require background knowledge. Code length: Mostly concise; repetitive delegation methods are appropriate for a wrapper, but several unused imports add clutter. Action granularity: Statements generally perform one action per line, and multiline expressions are formatted clearly. Reading flow: Methods progress naturally from setup to properties and rendering support. The lengthy initializer and get_context method slightly increase cognitive load, while manual URL parameter construction and compact tuple unpacking require closer attention.
Run 3
Code Structure: Well-organized class with distinct initialization, property delegation, URL generation, and context construction methods. Nesting: Shallow conditionals and no deeply nested control flow make scanning easy. Clarity of intent: Descriptive method names, permission flags, and explanatory comments communicate purpose, though framework-specific attributes, abbreviated names such as rel and info, and an externally defined AutocompleteMixin require context. Code length: Mostly concise; repetitive delegation methods are reasonable for a wrapper, while several unused imports add clutter. Action granularity: Statements generally perform one action per line, with longer calls and dictionaries formatted clearly. Reading flow: Natural progression from setup to rendering support and delegation; the lengthy initializer and get_context method slightly slow comprehension. Overall, readable and maintainable, with minor contextual dependencies and import noise.