Sample
pyint-685da7375558-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.011 | 0–1; higher is more readable |
| Mi | 0.78 | 0–1; higher is more readable |
| LLOC | 183 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.572 | 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. | 15664.707 | −516.935 |
| Source linesThe number of non-empty source lines. | 438 | +175.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.112 | −6.168 |
Intercept 8.87 + feature contributions = -339.033 (log-odds).
Score = sigmoid(-339.033) = 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. | 439 | −14.507 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 438 | +14.413 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 438 | −9.63 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 437.921 | +5.711 |
| 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.063 | +0.334 |
| 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.964 | −0.061 |
Intercept 0.07 + feature contributions = -4.474 (log-odds).
Score = sigmoid(-4.474) = 0.011.
| Score | 0.78 |
|---|
| Score | 183 |
|---|
Run 1
The code is well-structured with clear class organization and logical method grouping. Nesting is minimal, with only one level of indentation in methods like _check_unique_target. Intent is clearly expressed through descriptive method names and docstrings. Code length is appropriate for Django framework code, with no unnecessary verbosity. Action granularity is good - most lines contain one operation. Reading flow is natural, with methods ordered logically from initialization to validation to resolution. The code follows Django's established conventions and is highly maintainable for those familiar with Django's internals.
Run 2
This Django ForeignObject class is a complex model field implementation with deeply nested logic and excessive blank lines making it hard to follow. Imports are organized, but the class structure shows poor readability: methods contain multiple nested conditionals (e.g., _check_unique_target with 4+ levels), long intricate boolean expressions with comment explanations for unusual cases, and inconsistent use of magic strings like RECURSIVE_RELATIONSHIP_CONSTANT (undefined in this excerpt). Multiple actions appear on single lines (e.g., chained super() calls, tuple comprehensions with conditionals). The code is concise in parts but loses clarity due to complex domain logic without docstrings explaining intent. Vertical whitespace appears random with 2-3 blank lines between methods and inline comments referencing Django internals without context. The non_db_attrs property has redundant return statements showing unclear flow. Overall, while this code follows Django conventions, readability suffers from high cyclomatic complexity and dense conditional logic requiring deep framework knowledge.
Run 3
The code is highly readable with clear structure and intent. It uses logical organization with well-named methods and classes. Nesting is reasonable, though some methods like _check_unique_target have moderate nesting levels. Action granularity is mostly one action per line. The reading flow is natural, with methods grouped by functionality. However, there are minor readability issues: excessive blank lines in imports and class definition, some unnecessary comment placeholders (empty comments), and a few long methods that could be broken down further. The type hints are absent, and some complex logic (particularly in _check_unique_target) could benefit from more explanatory comments. The code follows Django conventions well and maintains consistent formatting throughout.
Run 1
Code Structure: Well organized into focused methods for validation, field resolution, relationship metadata, and class integration. Nesting: Mostly shallow with early returns, although validation and deconstruction contain moderately nested branches. Clarity of intent: Descriptive method and variable names help, but missing documentation and unexplained Django internals obscure subtle behavior; RelatedField and RECURSIVE_RELATIONSHIP_CONSTANT are not defined in this excerpt. Code length: Generally justified by functionality, though repetitive error construction, numerous imports unused in the excerpt, and excessive blank lines add bulk. Action granularity: Statements generally perform one action each, and multiline expressions are formatted clearly. Reading flow: Related methods are grouped naturally and formatting is consistent, but dense uniqueness checks and framework-specific metadata access require careful reading.
Run 2
Code Structure: Responsibilities are logically separated into validation, field resolution, metadata, and descriptor methods, although the class is large. Nesting: Most methods are shallow and use early returns; validation and deconstruction contain moderately nested branches. Clarity of intent: Descriptive method and variable names help, but missing docstrings and explanatory comments obscure framework-specific behavior. RelatedField and RECURSIVE_RELATIONSHIP_CONSTANT are not defined or imported in the excerpt, reducing self-contained clarity. Code length: Most methods are concise, but verbose error construction, repeated validation patterns, numerous unused imports in this excerpt, and excessive blank lines add noise. Action granularity: Statements generally perform one action each, with readable multiline calls and comprehensions. Reading flow: Consistent indentation and sensible method grouping support navigation, while dense metadata expressions, inheritance dependencies, and unexplained special cases interrupt understanding.
Run 3
Code Structure: Well-separated methods organize validation, field resolution, relationship traversal, and class integration, although the broad import list adds clutter. Nesting: Mostly shallow, with early returns improving readability; validation and deconstruction contain some deeper branches. Clarity of intent: Descriptive method and variable names communicate most responsibilities, but missing documentation and unexplained Django internals make edge cases difficult to understand. RelatedField and RECURSIVE_RELATIONSHIP_CONSTANT are not defined or imported in this excerpt, reducing self-contained clarity. Code length: Reasonable for the functionality, though repeated validation patterns and lengthy error construction increase scanning effort. Action granularity: Generally one operation per statement, with appropriately formatted multiline calls and comprehensions. Reading flow: Consistent formatting and related methods grouped together support natural reading, but excessive blank whitespace and transitions between framework-specific responsibilities interrupt the flow.