Sample
pyint-606529c832a5-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.668 | 0–1; higher is more readable |
| Mi | 0.569 | 0–1; higher is more readable |
| LLOC | 18 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.453 | 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. | 660.331 | −21.791 |
| Source linesThe number of non-empty source lines. | 22 | +8.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.71 | −7.065 |
Intercept 8.87 + feature contributions = -11.186 (log-odds).
Score = sigmoid(-11.186) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 59.957 | +1.126 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.071 | +0.253 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 23 | +0.222 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 21.754 | −0.106 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 22 | −0.084 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 22 | +0.024 |
Intercept 0.07 + feature contributions = 0.7 (log-odds).
Score = sigmoid(0.7) = 0.668.
| Score | 0.569 |
|---|
| Score | 18 |
|---|
Run 1
The code is highly readable with a clear, logical structure. The class PassList inherits from JSONTag and implements its interface cleanly, with each method performing a distinct action. Nesting is minimal, and the code is concise, avoiding unnecessary length. Intent is evident: the class handles serialization of list types by tagging each item. Action granularity is appropriate, with one clear operation per line, and the reading flow follows a natural sequence from type checking to serialization. Minor deductions are for the redundant tag = to_json assignment, which is slightly ambiguous without context, but overall the code is well-organized and easy to follow.
Run 2
The code is generally well-structured and readable. It uses clear imports, type hints, and a simple class definition with `__slots__` for efficiency. The `PassList` class has a clear purpose: serializing lists for a JSON tagging system. The `check` method is a straightforward type guard, and `to_json` uses a concise list comprehension. The alias `tag = to_json` is slightly ambiguous but likely intentional for API compatibility. Overall, the code is flat, concise, and easy to follow, though a brief comment explaining the purpose of the class or the `tag` alias would improve clarity.
Run 3
The code is generally readable with clear structure and organization. Imports are properly grouped and formatted, the class has a clear single responsibility, and method names are descriptive. Action granularity is good with one operation per line. Nesting is minimal. The main readability issues are: (1) unused imports (b64decode, b64encode, datetime, UUID, Markup, http_date, parse_date, dumps, loads) which add noise and ambiguity about intent, (2) the 'tag = to_json' alias at the bottom lacks explanation of why both methods exist, and (3) while concise, the class would benefit from a docstring explaining the PassList purpose and how it differs from the parent JSONTag class.
Run 1
Code Structure: The class is logically organized into type checking, conversion, and an alias, although many imports are unused in this excerpt and JSONTag is not defined or imported. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Method names and the list comprehension clearly convey checking for lists and tagging their contents, but PassList and the tag alias require some framework context. Code length: The implementation is concise, with unnecessary imports adding visual clutter. Action granularity: Each statement performs one clear action; the comprehension expresses a straightforward transformation. Reading flow: Imports followed by a small class provide a natural progression, though additional spacing between imports and the class would improve readability.
Run 2
Code Structure: The class is logically organized into type checking and JSON conversion, but numerous unused imports add clutter, and JSONTag is not defined or imported in the snippet. Nesting: There is no deep nesting; the list comprehension is straightforward. Clarity of intent: Method names and the isinstance check make the purpose clear, though the tag alias and inherited serializer require external context. Code length: The implementation is concise, but the import block is disproportionately long for the functionality shown. Action granularity: Each statement performs a focused action; the comprehension naturally combines iteration and conversion. Reading flow: The methods are easy to follow, although a blank line between imports and the class would improve separation.
Run 3
Code Structure: The class is logically organized into small, focused methods, but numerous unused imports add clutter, and JSONTag is not defined or imported in the snippet. Nesting: Minimal nesting; the list comprehension is straightforward. Clarity of intent: check clearly identifies lists, and to_json tags each item, though PassList and the tag alias require framework context. Code length: The implementation is concise, but the import block is disproportionately long for the functionality shown. Action granularity: Each line performs one clear action, with a simple comprehension expressing the transformation compactly. Reading flow: The methods follow a natural check-then-convert sequence, although import clutter and limited spacing between top-level sections slightly disrupt scanning.