Sample
pyint-a8e5471be73f-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.489 | 0–1; higher is more readable |
| Mi | 0.403 | 0–1; higher is more readable |
| LLOC | 48 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.484 | 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. | 2665.702 | −87.968 |
| 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.505 | −6.757 |
Intercept 8.87 + feature contributions = -39.855 (log-odds).
Score = sigmoid(-39.855) = 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.932 | +1.197 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.032 | +0.636 |
| 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.991 | −0.019 |
Intercept 0.07 + feature contributions = -0.046 (log-odds).
Score = sigmoid(-0.046) = 0.489.
| Score | 0.403 |
|---|
| Score | 48 |
|---|
Run 1
The code is well-structured and follows Django middleware conventions, with clear separation of concerns across methods. It demonstrates good action granularity, typically performing one logical action per line. Nesting is minimal and manageable, with early returns and guard-style conditions enhancing readability. The abundant docstrings and comments provide clear intent, explaining not just what the code does but why. Variable and method names are descriptive. The code length is appropriate for the functionality—concise without sacrificing clarity. The reading flow is natural, with request processing logic followed by response handling. Minor deductions: the method `should_redirect_with_slash` contains slightly more complex conditional logic, and the long RuntimeError message string interrupts flow somewhat, though it is necessary for user guidance. Overall, this is highly readable production-quality code.
Run 2
The code is highly readable due to its clear structure, minimal nesting, and natural reading flow. Each method has a single responsibility with descriptive names and docstrings explaining intent. Action granularity is mostly one action per line, and the code is concise without being overly brief. Nesting is shallow, with only small conditional blocks. The primary minor deductions are for a few multi-line statements (e.g., the RuntimeError message and the f-string redirect) that slightly interrupt reading flow, and one slightly long if-condition. Overall, the code closely follows clean code principles.
Run 3
The code is highly readable with clear class and method structure, good docstrings, and logical organization. Nesting is minimal with early returns and guard clauses. Each method has a single, well-defined purpose. Variable and method names effectively communicate intent. The code is concise, avoids unnecessary repetition, and maintains a consistent action-per-line style. Reading flow is natural, with comments explaining non-obvious decisions. Minor deductions for the slightly complex `should_redirect_with_slash` logic and the sparse comment in the middle of that method, which slightly interrupt flow.
Run 1
Code Structure: Well-organized middleware methods separate request checks, slash handling, and response processing. Nesting: Mostly shallow, though user-agent checks and slash validation reach three nested levels and could use guard clauses. Clarity of intent: Descriptive method names, docstrings, and comments clearly explain behavior and important redirect constraints. Code length: Generally proportionate to functionality, but lengthy documentation, some redundant comments, and unused imports add clutter. Action granularity: Statements generally perform one action per line; multiline expressions remain readable. Reading flow: Methods follow a natural request-to-helper-to-response progression, with consistent formatting. Minor distractions include an unnecessary blank line, redundant parentheses around match.func, and mixed string-formatting styles.
Run 2
Code Structure: Well-organized middleware with separate methods for request handling, slash validation, path construction, and response handling. Nesting: Generally moderate, but user-agent checks and slash validation reach three levels and could be flattened. Clarity of intent: Descriptive names, docstrings, and explanatory comments make behavior clear; unused imports introduce minor distraction. Code length: Mostly proportionate to functionality, though documentation is somewhat verbose and a few comments repeat the code. Action granularity: Statements generally perform one action per line, with readable multiline expressions and error construction. Reading flow: Methods follow a natural request-to-response sequence, and helpers isolate details effectively. Minor inconsistencies, including mixed string-formatting styles, redundant parentheses around match.func, and stray whitespace, slightly reduce polish.
Run 3
Code Structure: Well-organized middleware class with focused methods separating request checks, redirect decisions, path construction, and response handling. Nesting: Generally manageable, but user-agent validation and slash checks reach three nested levels and could benefit from guard clauses. Clarity of intent: Descriptive names, docstrings, and comments clearly explain behavior and important redirect constraints. Code length: Mostly proportionate to the functionality, though some comments repeat the code and several imports are unused. Action granularity: Statements generally perform one action per line; multiline expressions are formatted clearly. Reading flow: Methods follow a natural request-to-response progression, with helper methods placed logically. Minor distractions include an unnecessary blank line, redundant parentheses around match.func, and mixed string-formatting styles.