Sample
pyint-c08262236fb4-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.024 | 0–1; higher is more readable |
| Mi | 0.802 | 0–1; higher is more readable |
| LLOC | 188 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.59 | 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. | 15751.83 | −519.81 |
| Source linesThe number of non-empty source lines. | 461 | +184.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.185 | −6.277 |
Intercept 8.87 + feature contributions = -332.818 (log-odds).
Score = sigmoid(-332.818) = 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. | 462 | −15.322 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 418 | +13.721 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 418 | −9.171 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 460.921 | +6.033 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.351 | +0.605 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.417 |
| 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. | 87.957 | −0.06 |
Intercept 0.07 + feature contributions = -3.706 (log-odds).
Score = sigmoid(-3.706) = 0.024.
| Score | 0.802 |
|---|
| Score | 188 |
|---|
Run 1
The code is generally readable and well-structured, following Django's conventions. It uses clear method names, docstrings, and logical grouping. However, the complexity of the domain logic and some long methods reduce readability. The `__init__` method has many parameters, and methods like `_check_unique_target` and `get_instance_value_for_fields` are dense with nested conditions and multi-line expressions. Import statements are organized but lengthy. The code would benefit from breaking down complex validation logic into smaller helper methods. The use of type hints is absent, and some string formatting is inconsistent (mixing % and f-strings). While the code maintains a reasonable flat structure, certain methods contain deep nesting and complex boolean logic that could be simplified. Overall, it's readable for experienced Django developers but challenging for newcomers.
Run 2
The code shows good structure with clear class organization and logical grouping of methods, but suffers from moderate readability issues. The nesting is generally manageable, though some methods have three levels of indentation. While the intent of most methods is clear, some methods like _check_unique_target and deconstruct are quite long and complex. The code length is reasonable for a Django field implementation but could be broken down further - _check_unique_target in particular handles multiple distinct validation scenarios. Action granularity is mostly good with one action per line, though some parameter lists are dense. The reading flow is natural with methods ordered logically from initialization through checks to relationship resolution. The heavy use of list comprehensions in some methods slightly reduces clarity, and the complex conditional logic in methods like _check_unique_target would benefit from extraction into smaller helper methods to improve readability.
Run 3
The code demonstrates good structure with clear class organization, logical method grouping, and consistent patterns. Nesting is generally well-managed, though the _check_unique_target method contains deep conditional logic (up to 4 levels). Intent is clear throughout with descriptive method and variable names. Code length is appropriate given the complexity of Django's ForeignKey implementation. Action granularity is mostly one-per-line, though some comprehensions and conditional expressions pack multiple actions. Reading flow is natural, with methods following a logical progression. However, the file starts with heavy imports that could be better organized, and some methods like get_instance_value_for_fields and _check_unique_target could benefit from extraction of helper methods to reduce cognitive load. The mix of string formatting styles (%s vs f-strings) is inconsistent. Overall, this is maintainable, readable code typical of mature Django internals, but not exemplary due to occasional complexity and formatting inconsistencies.
Run 1
Code Structure: Well-organized class with focused methods separating validation, field resolution, metadata, and descriptor setup. Nesting: Mostly shallow, aided by early returns, though validation and deconstruction contain several nested branches. Clarity of intent: Descriptive method names, explicit arguments, docstrings, and comments explain purpose and edge cases; framework-specific internals and names absent from the excerpt require outside context. Code length: The class is substantial but largely justified by its responsibilities; repeated error construction and verbose expressions increase reading effort. Action granularity: Statements generally perform one action each, with readable multiline calls and comprehensions. Reading flow: Related methods are grouped naturally and formatting is consistent, but long metadata chains, complex uniqueness checks, and numerous imports make scanning harder.
Run 2
Code Structure: Responsibilities are logically separated into validation, field resolution, metadata, and descriptor methods, although the class covers many concerns. Nesting: Mostly shallow, with guard clauses reducing indentation; validation and deconstruction contain some deeper branches. Clarity of intent: Descriptive method names, docstrings, and comments explain framework-specific behavior, but dense metadata access and externally defined symbols require Django knowledge. Code length: The class is long but largely justified by its functionality; repeated error construction and parallel accessor methods add some verbosity. Action granularity: Statements generally perform one action each, and multiline calls make arguments easy to distinguish. Reading flow: Consistent formatting and related methods grouped together support natural reading, though complex uniqueness expressions and frequent transitions between framework mechanisms increase cognitive load.
Run 3
Code Structure: Well organized into focused methods, with validation, field resolution, accessors, and relationship registration clearly separated. Nesting: Mostly shallow, supported by early returns; validation and deconstruction contain some moderately nested branches. Clarity of intent: Descriptive method names, docstrings, and explanatory comments make purposes clear, though Django internals, abbreviated variables, and references not defined in the snippet require external context. Code length: The class is long but largely justified by its responsibilities; repeated error construction and parallel accessor methods add some verbosity. Action granularity: Statements generally perform one action each, and multiline calls and comprehensions are formatted cleanly. Reading flow: Consistent formatting and logical method grouping support scanning, although complex uniqueness expressions and frequent metadata traversal slow detailed reading.