Sample
pyint-8642c9e8e7a2-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.02 | 0–1; higher is more readable |
| Mi | 0.802 | 0–1; higher is more readable |
| LLOC | 182 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.58 | 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. | 15651.213 | −516.49 |
| Source linesThe number of non-empty source lines. | 457 | +182.8 |
| 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.19 | −6.284 |
Intercept 8.87 + feature contributions = -331.104 (log-odds).
Score = sigmoid(-331.104) = 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. | 458 | −15.18 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 414 | +13.583 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 414 | −9.079 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 456.907 | +5.977 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.745 | +0.74 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.409 |
| 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. | 95.976 | −0.4 |
Intercept 0.07 + feature contributions = -3.88 (log-odds).
Score = sigmoid(-3.88) = 0.02.
| Score | 0.802 |
|---|
| Score | 182 |
|---|
Run 1
The code demonstrates good readability overall. Structure is logical with clear method separation and sensible imports. Nesting is generally flat, though _check_unique_target has some deeper conditional nesting. Intent is clear from docstrings and method names. The code is concise in some areas but verbose in others, particularly in error message construction. Action granularity is mostly one action per line, but a few lines combine multiple operations (e.g., related_fields.append with nested conditionals). Reading flow is natural, following Django's conventions. Some minor issues include a few very long lines that would benefit from wrapping, and occasional dense expressions that could be extracted for clarity. The use of tuple comprehensions and generators is generally good. The blank lines with trailing spaces in resolve_related_fields are slightly distracting. Overall, this is well-written Django framework code that balances complexity with maintainable structure.
Run 2
The code has clear structure and follows Django conventions, with methods logically grouped and generally well-documented docstrings. However, readability suffers from inconsistent nested logic, particularly in _check_unique_target() which contains deeply conditional blocks. Some methods like resolve_related_fields() have poorly formatted multi-line expressions that hurt readability. The code length is appropriate for Django field implementations but some methods could be refactored into smaller helpers. Most lines perform single actions, though several list comprehensions and conditional assignments pack multiple operations. Imports are well-organized. While variable names are descriptive and intent is mostly clear, the deep nesting and complex boolean logic in validation methods require significant effort to follow. The code is readable for experienced Django developers but would benefit from cleaner formatting and reduced nesting in validation methods.
Run 3
The code is complex and difficult to read due to several factors: deep nesting with multiple conditional layers, long and redundant method names, inconsistent formatting, and multiple actions per line (especially in variable assignments and list comprehensions). While it follows some standard Django patterns, the logical flow is often unclear, and the code mixes many responsibilities without clear separation. The imports are overly broad, and the use of nested ternary-like expressions and complex conditional logic adds to the cognitive load. Although comments are used sparingly, they don't always clarify intent effectively. Overall, this is a low-to-moderate readability score, as the code would likely require frequent re-reading and domain expertise to understand fully.
Run 1
Code Structure: Well organized into focused methods for validation, relationship resolution, metadata, and descriptors. Nesting: Mostly shallow with early returns, though validation and deconstruction contain several nested branches. Clarity of intent: Descriptive method names, comments, and docstrings explain complex ORM behavior; framework-specific concepts and definitions absent from the excerpt require external context. Code length: Generally justified by functionality, although verbose error construction and repeated metadata access add bulk. Action granularity: Most statements perform one action, but resolve_related_fields compresses field selection and tuple construction into a difficult-to-scan append expression. Reading flow: Method grouping and consistent conventions support navigation, while irregular blank lines, unnecessary parentheses, and a crowded get_class_lookups return disrupt otherwise natural flow.
Run 2
Code Structure: Well-organized class with focused methods separating validation, field resolution, metadata, and descriptor setup. Nesting: Mostly moderate, with early returns reducing complexity; validation and deconstruction contain some deeper branches. Clarity of intent: Descriptive method names, comments, and docstrings explain behavior, although Django-specific internals require background knowledge and some referenced symbols are not defined in the snippet. Code length: Generally justified by functionality, but repetitive validation/error construction and unnecessary parentheses add bulk. Action granularity: Usually one operation per statement; resolve_related_fields compresses two conditional field resolutions and an append into one awkwardly formatted expression. Reading flow: Mostly consistent and natural, with related methods grouped together, but irregular blank lines, long expressions, and inconsistent formatting in a few methods interrupt scanning.
Run 3
Code Structure: Well-organized class with focused methods separating validation, relationship resolution, metadata, and descriptor setup. Nesting: Mostly shallow, aided by early returns, though uniqueness checks and deconstruction contain moderately nested branches. Clarity of intent: Descriptive method names, comments, and docstrings explain most behavior; framework-specific concepts and undefined names in the snippet require external context. Code length: Generally justified by functionality, although repeated error construction and verbose expressions add bulk. Action granularity: Most statements perform one clear action, but resolve_related_fields compresses two conditional field resolutions and tuple construction into one awkward append expression. Reading flow: Method grouping and consistent conventions support navigation, but irregular blank lines, unnecessary parentheses, and a long get_class_lookups return interrupt an otherwise natural flow.