Sample
pyint-784fcf2c7e09-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.001 | 0–1; higher is more readable |
| Dorn | 0.523 | 0–1; higher is more readable |
| Mi | 0.464 | 0–1; higher is more readable |
| LLOC | 35 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9.33 | 0–20; mean of three runs |
| BTTF | 0.576 | 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. | 1812.586 | −59.815 |
| 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.512 | −6.768 |
Intercept 8.87 + feature contributions = -7.314 (log-odds).
Score = sigmoid(-7.314) = 0.001.
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.881 | +1.35 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 46 | +0.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 99.969 | +0.809 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.031 | +0.643 |
| 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. | 99.984 | −0.57 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.094 (log-odds).
Score = sigmoid(0.094) = 0.523.
| Score | 0.464 |
|---|
| Score | 35 |
|---|
Run 1
The code has severe readability issues. Structure is disjointed: the method is named `as2`, but references `view` and `vie` inconsistently, with undefined variables like `class_args` and `class_kwargs`. Nesting is moderate but muddled by ambiguous logic. Intent is confusing — the class attributes are documented well, but the implementation contradicts names (`dispatch` vs expected `dispatch_request`, `self` used inside a static-like view function). Code length is verbose due to excessive comments, yet the actual logic is incomplete and broken. Action granularity is poor: multiple operations occur per line, mixing assignments, calls, and type ignores. Reading flow is unnatural, jumping between `vie`, `view`, and `sel`. The overall effect is unreadable, error-prone code that fails to clearly express its purpose or function correctly.
Run 2
The code has serious readability issues. Variable names are confusing and inconsistent ('as2', 'nam', 'sel', 'sel2', 'vie', 'kwa', 'kwa2'), and there are apparent bugs (undefined variables 'class_args'/'class_kwargs', inconsistent use of 'view_class' vs 'cls', 'self.dispatch' used instead of 'sel.dispatch'). The conditional branch creates server-side view instances with parallel but non-uniform code, and the decorator/attribute-assignment section is disconnected from the view function definition. While the class-level docstrings are clear, the method implementation lacks coherent structure and natural reading flow. Action granularity is poor; multiple concerns are packed into single expressions. The nesting is shallow, but clarity of intent is undermined by poor naming and unclear variable references. Overall, this code is difficult to read, understand, and maintain.
Run 3
The code has a clear overall class structure with good docstrings, but it contains several critical readability issues. The method `as2` uses confusing parameter names (`class2`, `class3`) that obscure intent, and there are undefined or inconsistent variable names (`class_args`, `class_kwargs`, `sel2`, `self.dispatch` inside the else branch, `vie` vs `view`). The conditional logic splits into two branches that create different view functions, increasing cognitive complexity. Some lines perform multiple actions or contain long comments that break flow. The docstrings are informative but oversized relative to the code they describe, adding visual clutter. While the concepts are understandable, the implementation details and naming inconsistencies undermine clarity.
Run 1
Code Structure: Class attributes and methods are logically organized, but inconsistent identifiers undermine coherence. Nesting: Moderate nesting in conditional function definitions and the decorator loop remains manageable. Clarity of intent: Detailed documentation explains the intended design, but names such as as2, nam, class2, sel2, and vie are unclear. References to undefined class_args, class_kwargs, self, and vie force readers to infer intended relationships. Documentation also refers to dispatch_request and as_view rather than the implemented dispatch and as2. Code length: Implementation is reasonably concise, though extensive documentation outweighs the executable code. Action granularity: Most lines perform one clear action, with no compressed multi-statement lines. Reading flow: The progression from configuration to dispatch to view generation is natural, but naming mismatches, inconsistent references, and long inline type-ignore comments repeatedly interrupt comprehension.
Run 2
Code Structure: Class attributes and methods are logically organized, but inconsistent identifiers undermine cohesion. Nesting: Mostly shallow, with manageable conditional branches, nested functions, and a decorator loop. Clarity of intent: Documentation explains the intended behavior, but names such as as2, nam, class2, sel2, and vie obscure meaning. References to undefined class_args, class_kwargs, self, and vie make execution difficult to follow; documentation also refers to dispatch_request and as_view rather than the implemented methods. Code length: Implementation is reasonably concise, although extensive documentation dominates and includes misleading references. Action granularity: Most lines perform one clear action, with only moderately dense callable expressions. Reading flow: The progression from configuration to dispatch and view creation is natural, but mismatched names and repeated metadata assignments force readers to reconstruct the intended relationships.
Run 3
Code Structure: Class attributes, dispatch behavior, and view creation are logically grouped, but inconsistent identifiers disrupt coherence. Nesting: Moderate and manageable, with nested functions inside an if/else and a decorator loop. Clarity of intent: Documentation explains the intended design, but names such as as2, class2, sel2, and vie are ambiguous. Undefined references including class_args, class_kwargs, self, and vie make the implementation difficult to follow, while documentation references methods absent from the code. Code length: Implementation is reasonably concise, although extensive documentation adds scanning overhead and conflicts with actual names. Action granularity: Most lines perform one clear operation; chained calls remain understandable. Reading flow: The overall sequence is natural, but mismatched names repeatedly force readers to infer relationships and intended behavior.