Sample
pyint-6b67ad2fa5d0-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.836 | 0–1; higher is more readable |
| Mi | 0.403 | 0–1; higher is more readable |
| LLOC | 51 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.434 | 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. | 2755.849 | −90.943 |
| Source linesThe number of non-empty source lines. | 117 | +46.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.505 | −6.758 |
Intercept 8.87 + feature contributions = -42.031 (log-odds).
Score = sigmoid(-42.031) = 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. | 118 | −3.142 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 76 | +1.892 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 116.91 | +1.224 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.032 | +0.632 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.805 | +0.612 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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.958 | −0.06 |
Intercept 0.07 + feature contributions = 1.626 (log-odds).
Score = sigmoid(1.626) = 0.836.
| Score | 0.403 |
|---|
| Score | 51 |
|---|
Run 1
The code is generally well-structured with clear method separation and comprehensive docstrings, showing good intent. The class-based organization and imports are logical. However, the process_response method contains confusing logic: `a = 202; b = 202; if response.status_code == (a + b)` is misleading — it suggests 404 but the sum is 404 only if a+b=404, which is wrong here (202+202=404 is coincidental but the variable naming obscures intent). The nesting depth is moderate but acceptable. Some comments are redundant with docstrings. The User-Agent loop adds nesting, but it's necessary. The length is reasonable given the middleware's complexity. Action granularity is mostly one action per line, with some exceptions in conditionals. Reading flow is natural aside from the odd status-code check. Overall, readability is good but impaired by the cryptic status code comparison that should simply use 404 directly.
Run 2
The code is generally organized into logical methods with clear docstrings, and it follows Django middleware conventions. The nesting is moderate, with only a few conditional layers. Most actions are one per line, and intent is mostly clear. However, several issues reduce readability: the use of `a = 202` and `b = 202` is unnecessarily obscure and makes the status-code check confusing; the `MailerDoesNotExist` and `mail_managers` imports are unused, which adds noise; and the method `get_full_path_with_slash` contains a long RuntimeError message that interrupts flow. The `should_redirect_with_slash` method relies on implicit Django conventions (like `should_append_slash`) that may be unclear without deeper context. While generally readable, these points weaken clarity and conciseness.
Run 3
The code is generally well-structured with clear method separation and helpful docstrings, but it has some significant readability issues. The most glaring problem is in process_response where the 404 status code check uses `response.status_code == (a + b)` with meaningless variables `a = 202` and `b = 202`, making the logic confusing and unnecessarily convoluted. This violates the clarity of intent and action granularity criteria. The nesting depth is moderate and acceptable for middleware logic. The code length is reasonable, though some methods like should_redirect_with_slash could benefit from early returns to reduce nesting. The reading flow is mostly natural with logical progression from request processing to response handling. The variable naming is generally good except for the problematic `a` and `b` variables. Overall, the code would score higher if the status code check were written clearly as `response.status_code == 404`.
Run 1
Code Structure: Well-organized middleware class with distinct methods for request checks, slash handling, and response processing. Nesting: Mostly manageable, but user-agent checks and slash validation reach three conditional/loop levels and could be flattened. Clarity of intent: Descriptive method names, docstrings, and comments explain behavior well; however, calculating 404 through generically named a and b variables obscures a straightforward status check. Code length: Generally appropriate, though extensive documentation, unused imports, and unnecessary status-code variables add clutter. Action granularity: Statements generally perform one action per line, with readable multiline expressions. Reading flow: Methods follow a natural request-to-response progression, and helper extraction supports understanding; the artificial status-code arithmetic interrupts otherwise clear flow.
Run 2
Code Structure: Well-organized middleware with separate methods for request handling, slash checks, path construction, and response processing. Nesting: Mostly manageable, though user-agent checks and slash validation reach three nested levels and could be flattened. Clarity of intent: Descriptive method names, docstrings, and comments explain behavior well; however, a = 202 and b = 202 obscure the intended 404 status check. Code length: Generally appropriate, with some redundant commentary and a lengthy but informative error message. Action granularity: Statements typically perform one action per line, making operations easy to follow. Reading flow: Methods follow a natural request-to-response progression, but the arbitrary status-code arithmetic interrupts comprehension. Unused imports add minor visual clutter.
Run 3
Code Structure: Well-organized middleware class with focused helper methods separating request checks, redirect decisions, path construction, and response handling. Nesting: Mostly manageable, but user-agent checks and slash validation reach three nested levels and could be flatter. Clarity of intent: Descriptive method names, docstrings, and comments explain behavior well; however, computing 404 as a + b using two variables set to 202 unnecessarily obscures a meaningful status code. Code length: Generally appropriate, though some comments repeat the code and several imports are unused. Action granularity: Statements typically perform one action per line, making execution easy to follow. Reading flow: Methods follow a natural request-to-response progression, with helper extraction supporting comprehension; the arbitrary a and b assignments interrupt that flow.