Sample
pyint-f1c66b57ce26-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.003 | 0–1; higher is more readable |
| Dorn | 0.458 | 0–1; higher is more readable |
| Mi | 0.464 | 0–1; higher is more readable |
| LLOC | 34 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs |
| BTTF | 0.607 | 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. | 1771.472 | −58.459 |
| Source linesThe number of non-empty source lines. | 126 | +50.4 |
| 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.518 | −6.777 |
Intercept 8.87 + feature contributions = -5.965 (log-odds).
Score = sigmoid(-5.965) = 0.003.
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. | 127 | −3.46 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 125.82 | +1.349 |
| 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. | 109.992 | −0.994 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 109.976 | +0.97 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 46 | +0.854 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.031 | +0.645 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -0.168 (log-odds).
Score = sigmoid(-0.168) = 0.458.
| Score | 0.464 |
|---|
| Score | 34 |
|---|
Run 1
The code is well-structured with clear class-level attributes and docstrings. Methods are separated logically, and the `as_view` function uses a flat if/else for init behavior, keeping nesting shallow. Type hints and comments improve clarity. However, the `as_view` method is somewhat dense, with multi-action lines (e.g., nested function call chaining) and inline type ignores that add noise. Line length and inline comments like `# We attach the view class...` help intent but the `view` inner function definitions slightly disrupt reading flow. Overall readable but could be more concise.
Run 2
The code is generally well-structured with clear class-level documentation, appropriate type hints, and logical separation of concerns. The docstrings are detailed and helpful, which improves clarity of intent. However, readability suffers in the `as_view` method: the nested function definitions and the complex expression combining `current_app.ensure_sync`, class instantiation, and method dispatch on a single line make it harder to parse. There is also some duplication between the two branches of the conditional, and several `type: ignore` comments add visual noise. Nesting is moderate but the dense logic in `view` functions reduces readability. Action granularity is inconsistent — some lines pack multiple operations while others are well separated. Overall, it is readable for experienced developers familiar with Flask internals, but could be simplified by extracting helper methods or breaking down complex expressions into intermediate variables.
Run 3
The code is highly readable with clear structure and intent. It uses logical class organization, descriptive names, and concise docstrings that explain its purpose. Nesting is minimal, though the `current_app.ensure_sync` call is slightly dense with inline comments. Action granularity is mostly one action per line, but some lines combine multiple operations (e.g., the dispatch call). The reading flow is natural, and the code length is justified by necessary documentation and configuration attributes. Minor reductions in nested function call complexity and denser inline comments would improve clarity.
Run 1
Code Structure: The class is logically organized into configuration attributes, an override hook, and a view factory. Nesting: Mostly shallow, although conditional nested function definitions and a decorator loop add moderate complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the lifecycle and configuration well; dynamic function attributes require closer attention. Code length: Executable code is reasonably concise, but extensive documentation and repeated metadata assignments lengthen the reading path. Action granularity: Most lines perform one action, but the per-request return expression combines instantiation, method lookup, synchronization, and invocation, making it harder to parse. Reading flow: Generally natural and sequential, with the dense multiline return expression, inline type-ignore comments, and an extra blank line interrupting flow.
Run 2
Code Structure: Logically organized into configuration attributes, an override hook, and a view factory. Nesting: Mostly shallow, with understandable conditional function definitions and a decorator loop. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain lifecycle choices and metadata attachment; dynamic function attributes add some complexity. Code length: Implementation is compact, although extensive documentation and repeated metadata assignments increase reading time. Action granularity: Most lines perform one action, but the per-request return expression combines instantiation, method lookup, synchronization, and invocation, making it harder to parse. Reading flow: Generally natural and sequential, but awkward expression wrapping, inline type-ignore comments, and extra whitespace interrupt an otherwise clean flow.
Run 3
Code Structure: Well-organized class with configuration attributes, a dispatch contract, and a view factory. Nesting: Moderate and justified, primarily conditional branches containing closures and a decorator loop. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain lifecycle behavior and metadata. However, dynamic function attributes and the compressed instance-creation/dispatch expression require extra interpretation. Code length: Implementation is reasonably concise; extensive documentation adds scanning overhead but provides useful context. Action granularity: Most lines perform one action, but the per-request return expression combines instantiation, method lookup, synchronization, and invocation. Reading flow: Generally natural, progressing from configuration to execution and metadata assignment. Awkward parentheses, long return lines, inline type-ignore comments, and redundant metadata assignments slightly disrupt the flow.