Sample
pyint-1b0ba91edb10-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.775 | 0–1; higher is more readable |
| Mi | 0.377 | 0–1; higher is more readable |
| LLOC | 18 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs |
| BTTF | 0.449 | 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. | 712.555 | −23.514 |
| Source linesThe number of non-empty source lines. | 24 | +9.6 |
| 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.726 | −7.088 |
Intercept 8.87 + feature contributions = -12.133 (log-odds).
Score = sigmoid(-12.133) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 76.48 | +0.43 |
| 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. | 76.92 | +0.407 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.319 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 25 | +0.151 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 22 | −0.084 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 23.795 | −0.077 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 22 | +0.024 |
Intercept 0.07 + feature contributions = 1.239 (log-odds).
Score = sigmoid(1.239) = 0.775.
| Score | 0.377 |
|---|
| Score | 18 |
|---|
Run 1
The code is highly readable. It has clear imports, a single class with two small methods, and flat logic. The purpose is explicit: detect dictionaries and serialize them with tagged values. The comment clarifies a design decision about key handling. Variable names are concise and appropriate. Each method performs one logical action per line. The overall flow is natural and easy to follow.
Run 2
The code is highly readable and well-structured. The class PassDict follows a clear, logical organization with a flat, non-nested structure. Each method has a single responsibility, and the action granularity is appropriate—one action per line in the to_json method. The intent is clear: the class provides a JSON tag for dict objects, serializing their values while avoiding unnecessary key tagging. The type annotations and use of `__slots__` enhance clarity and performance. The absence of a `from_json` method might seem incomplete, but the code snippet is likely part of a larger pattern. The docstring-style comment explains the design choice effectively. The imports are slightly verbose but follow a consistent style. Overall, the code is concise, maintains a natural reading flow, and successfully balances explicitness with brevity, though a small deduction for potential ambiguity regarding the class's role without seeing its parent class.
Run 3
The code is well-structured and highly readable. It uses clear imports with alphabetical ordering, type hints, and a minimal class definition with __slots__ for efficiency. The methods are flat, concise, and each performs a single logical action. The `check` method cleanly validates the type, while `to_json` uses a dictionary comprehension that is immediately clear in intent. The comment explains a non-obvious design decision about JSON keys. Slight deductions for the `tag = to_json` alias which, while a common pattern, can add minor indirection, and the lack of a docstring on the class itself. Overall the naming, spacing, and flow are excellent.
Run 1
Code Structure: The class is logically organized, with separate methods for type checking and conversion, although JSONTag is not defined or imported in the snippet. Nesting: Minimal nesting and a straightforward dictionary comprehension make the code easy to scan. Clarity of intent: Method names and the comment clearly convey dictionary serialization, though the tag alias and serializer dependency require external context. Code length: The implementation is concise, but numerous unused imports add clutter. Action granularity: Each line performs a focused action; the comprehension compactly expresses a single transformation. Reading flow: Imports, class declaration, and methods follow a natural order, with minor spacing improvements possible.
Run 2
Code Structure: The class is logically organized into type checking and serialization methods, although several imports appear unused and JSONTag is not defined or imported in the snippet. Nesting: Minimal nesting and a straightforward dictionary comprehension make the code easy to follow. Clarity of intent: Method names, type annotations, and the comment clearly convey dictionary serialization; the tag alias requires minor familiarity with the surrounding API. Code length: The implementation is concise, but the unused imports add clutter. Action granularity: Each statement performs a single clear action, with the comprehension expressing one cohesive transformation. Reading flow: Imports, class declaration, and methods follow a natural sequence, though additional spacing between imports and the class would improve visual separation.
Run 3
Code Structure: The class is logically organized into type checking and serialization, although numerous unused imports and the undefined-in-snippet JSONTag base add clutter and missing context. Nesting: Methods are flat, with only a straightforward dictionary comprehension. Clarity of intent: Descriptive method names and a useful comment explain dictionary handling; the tag alias and serializer dependency require some surrounding context. Code length: The class is concise, but the import list is excessive for the shown functionality. Action granularity: Each statement performs a clear action, and the comprehension expresses a cohesive transformation. Reading flow: Execution and purpose are easy to follow, though additional spacing between imports and the class would improve visual separation.