Sample
pyint-6a217d9b1744-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.49 | 0–1; higher is more readable |
| Mi | 0.403 | 0–1; higher is more readable |
| LLOC | 49 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.486 | 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. | 2677.348 | −88.352 |
| Source linesThe number of non-empty source lines. | 115 | +46 |
| 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.506 | −6.759 |
Intercept 8.87 + feature contributions = -40.241 (log-odds).
Score = sigmoid(-40.241) = 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. | 116 | −3.071 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 74 | +1.822 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 74 | −1.277 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 114.898 | +1.196 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.031 | +0.639 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.871 | +0.597 |
| 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.974 | −0.019 |
Intercept 0.07 + feature contributions = -0.042 (log-odds).
Score = sigmoid(-0.042) = 0.49.
| Score | 0.403 |
|---|
| Score | 49 |
|---|
Run 1
The code is well-structured and readable. The class has a clear purpose and logical organization, with methods separated by distinct responsibilities (request processing, URL redirect logic, response handling). Nesting is generally shallow, though process_request contains a slightly deeper conditional within the PREPEND_WWW check. Intent is clearly expressed through descriptive method names and informative docstrings. The code is concise without being terse, and each line primarily performs a single action. Reading flow is natural, following Django middleware conventions. Minor deductions: the docstring contains excessive line breaks in the section headers, and some conditional logic could be extracted for additional clarity, but overall this is professional-quality, maintainable code.
Run 2
The code demonstrates exceptional readability. It is logically organized into a well-documented class with clear, single-responsibility methods. The nesting is shallow, with conditionals kept to a maximum of two levels, contributing to a flat structure. Each method has a clear purpose, accurately described by docstrings and comments that explain the intent without stating the obvious. The code is concise; comments add valuable context about non-obvious decisions (e.g., performance concerns) rather than repeating code. Most lines execute a single action, maintaining good action granularity. The reading flow is natural: from request processing, to helper methods, to response processing, following the middleware lifecycle. Meaningful variable names like user_agent_regex and should_redirect_with_slash further enhance clarity.
Run 3
The code is highly readable with clear structure and intent. Each method has a single responsibility and well-written docstrings explaining its purpose. Nesting is minimal, with guard clauses and early returns improving flow. Action granularity is appropriate: most lines perform one logical operation, and variable names are descriptive. The reading flow follows a natural progression from request processing to response handling. Minor deductions: the docstring in CommonMiddleware is somewhat lengthy and includes implementation details that might become stale, and the conditional logic in process_request could arguably be split further for even flatter structure. The string formatting in the RuntimeError message is slightly verbose but still clear. Overall, this is exemplary Django middleware code that balances conciseness with clarity.
Run 1
Code Structure: Well-organized middleware with separate methods for request processing, redirect eligibility, path construction, and response processing. Nesting: Generally shallow, although user-agent checks and slash eligibility reach three nested levels and could benefit from guard clauses. Clarity of intent: Descriptive names, focused docstrings, and explanatory comments make behavior clear; unused imports add minor noise. Code length: Appropriately concise for the functionality, though some comments repeat the code and the class docstring is lengthy. Action granularity: Statements generally perform one action per line; multiline conditions and error-message construction remain readable. Reading flow: Methods follow a natural request-to-response sequence, with helper methods placed logically and consistent formatting throughout. Minor nesting and documentation verbosity prevent a perfect score.
Run 2
Code Structure: Well organized into focused middleware hooks and helper methods, with related responsibilities grouped logically. Nesting: Generally shallow, although user-agent checks and slash validation reach three conditional or loop levels and could benefit from guard clauses. Clarity of intent: Descriptive method names, docstrings, and comments clearly explain behavior and important redirect constraints. Code length: Mostly proportionate to the functionality; lengthy documentation and error text are useful, though some comments repeat obvious operations and several imports are unused. Action granularity: Statements generally perform one action per line, with readable multiline formatting for complex expressions. Reading flow: Request handling, redirect decisions, path construction, and response processing follow a natural sequence. Minor distractions include mixed string-formatting styles and redundant comments, but the code remains highly readable.
Run 3
Code Structure: Well-organized middleware with distinct methods for request checks, slash decisions, path construction, and response handling. Nesting: Mostly shallow, though user-agent filtering and slash validation reach three conditional/loop levels. Clarity of intent: Descriptive names, docstrings, and explanatory comments make behavior and redirect constraints clear. Code length: Generally proportionate to functionality; lengthy documentation and error messages are useful, but several unused imports add clutter. Action granularity: Statements generally perform one action per line, with multiline expressions formatted cleanly. Reading flow: Methods follow a natural request-to-response progression, and helper extraction keeps the main logic easy to follow. Minor drawbacks include inconsistent string formatting styles and opportunities to flatten conditional logic with early returns.