Sample
pyint-ce0844947702-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.479 | 0–1; higher is more readable |
| Mi | 0.408 | 0–1; higher is more readable |
| LLOC | 52 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.469 | 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. | 2786.314 | −91.948 |
| Source linesThe number of non-empty source lines. | 118 | +47.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.502 | −6.753 |
Intercept 8.87 + feature contributions = -42.631 (log-odds).
Score = sigmoid(-42.631) = 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. | 119 | −3.177 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 77 | +1.926 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 77 | −1.346 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 117.886 | +1.238 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.032 | +0.635 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.252 | +0.587 |
| 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.933 | −0.017 |
Intercept 0.07 + feature contributions = -0.083 (log-odds).
Score = sigmoid(-0.083) = 0.479.
| Score | 0.408 |
|---|
| Score | 52 |
|---|
Run 1
The code is generally well-structured with clear sections for different middleware operations, good docstrings, and reasonable nesting. However, there are some issues: the 'remaining_steps' loop in process_request appears to be incomplete/dead code, which creates ambiguity. The should_redirect_with_slash method has deeper nesting (if/if/if/match) that could be simplified. Function names and docstrings clearly convey intent, and the code is mostly concise with good action granularity though process_request could be broken into smaller methods. Reading flow is natural with logical progression from request processing to response handling.
Run 2
The code is well-structured and highly readable. It uses clear docstrings, logical method separation, and consistent formatting. However, there is a confusing unused 'while' loop in process_request that adds unnecessary noise and reduces clarity. Nesting is mostly flat with only minor conditional levels. Intent is clearly communicated through descriptive method names and comments. Action granularity is appropriate, with one main action per line. The reading flow is natural, following a logical progression of checks and redirects. Minor improvements could include removing the dead loop and simplifying the PREPEND_WWW conditional block.
Run 3
The code is generally readable with clear docstrings explaining intent, logical separation of methods, and mostly flat nesting. It follows Django conventions and uses descriptive method names. However, there are issues: a useless while loop in process_request (lines 15-17) that does nothing, which harms clarity; some methods like should_redirect_with_slash have moderate nesting; and the regex import is unused. The overall structure is decent but could be improved by removing dead code and unnecessary imports. The action granularity is mostly one action per line, but the while loop and conditional logic in process_request feel congested. Reading flow is natural, though the dead loop interrupts it. Score reflects good readability with minor but noticeable flaws.
Run 1
Code Structure: Responsibilities are logically separated into request handling, slash validation, path construction, and response handling. Nesting: Mostly manageable, but user-agent checking and slash validation reach three nested levels and could use guard clauses. Clarity of intent: Descriptive method names, docstrings, and comments explain the middleware well; the pointless remaining_steps loop introduces ambiguity, and unused imports add noise. Code length: Generally appropriate, though some documentation repeats the implementation and the no-op loop is unnecessary. Action granularity: Statements generally perform one action each, with readable multiline expressions and error formatting. Reading flow: Methods follow a natural request-to-response progression, with helper methods placed coherently; the unexplained loop interrupts that flow.
Run 2
Code Structure: Well-organized middleware with focused methods separating request checks, slash handling, and response processing; unused imports add clutter. Nesting: Generally manageable, but user-agent checks and slash validation reach three nested levels and could be flatter. Clarity of intent: Descriptive names, docstrings, and comments explain the behavior well; the pointless remaining_steps loop introduces ambiguity. Code length: Mostly appropriate, though the no-op loop and some repetitive documentation add unnecessary length. Action granularity: Statements generally perform one action per line, and multiline expressions remain readable. Reading flow: Methods follow a natural request-to-response progression, with helper methods supporting the main logic; the unrelated loop interrupts that flow.
Run 3
Code Structure: Responsibilities are logically separated into request processing, redirect checks, path construction, and response processing. Nesting: Generally manageable, though user-agent checks and slash validation reach three nested levels and could use flatter control flow. Clarity of intent: Descriptive method names, docstrings, and comments explain behavior well; the purposeless remaining_steps loop introduces ambiguity, and unused imports add noise. Code length: Mostly appropriate, but the redundant loop and some repetitive documentation unnecessarily extend it. Action granularity: Statements generally perform one action per line, with readable formatting for longer expressions and error messages. Reading flow: Methods follow a natural request-to-response progression, and helper methods keep complex details localized; the unexplained loop interrupts that flow.