Sample
pyint-d6ec6f06c954-I10
Deterministically remove some optional blank lines and bracketed line breaks
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.671 | 0–1; higher is more readable |
| Mi | 0.563 | 0–1; higher is more readable |
| LLOC | 18 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.448 | 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. | 21 | +8.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.71 | −7.065 |
Intercept 8.87 + feature contributions = -11.586 (log-odds).
Score = sigmoid(-11.586) = 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.909 | +1.128 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 22 | +0.257 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.071 | +0.253 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 20.803 | −0.119 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 21 | −0.061 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 21 | −0.011 |
Intercept 0.07 + feature contributions = 0.713 (log-odds).
Score = sigmoid(0.713) = 0.671.
| Score | 0.563 |
|---|
| Score | 18 |
|---|
Run 1
The code is difficult to read due to multiple issues. The Class `PassList` inherits from `JSONTag` but that base class is never imported, creating ambiguity. Several imports (`b64decode`, `b64encode`, `datetime`, `UUID`, `Markup`, `http_date`, `parse_date`, `loads`, `dumps`) are unused, adding noise and suggesting unclear intent. The `tag = to_json` alias is confusing—normally `tag` and `to_json` would be distinct methods in a tagging system. The methods are concise and mostly flat, but the missing base class makes the logic hard to evaluate. Formatting is inconsistent: no blank lines between methods, and import grouping is mixed. Overall, the code is syntactically short but semantically ambiguous due to missing context, unused dependencies, and unclear aliasing.
Run 2
The code is generally readable with clear imports and type hints. The class structure is logical, and method names like 'check' and 'to_json' indicate intent. The 'tag = to_json' alias at the bottom is a common pattern in serializer frameworks but reduces clarity slightly because it's not obvious why it's needed without context. The code is concise, flat, and each method performs a single logical action. However, the reading flow is somewhat disrupted: 'tag = to_json' appears after the methods without explanation, and the class lacks a docstring or clear context about how it fits into the broader serialization system. The lack of vertical spacing between methods is minor but impacts readability slightly. Overall, it's clean and maintainable, but it assumes familiarity with the framework's conventions.
Run 3
The code has several readability issues. Multiple unused imports (b64decode, b64encode, datetime, UUID, Markup, http_date, parse_date, dumps, loads) clutter the file and obscure intent. The class is incomplete—it inherits from JSONTag but that class is not imported or defined, making the code non-functional and confusing. The methods are simple and flat, which is good, but check() lacks a docstring or type constraints beyond Any. The line `tag = to_json` is concise but potentially unclear without context. Overall, the structure is logical but sparse; unused imports and missing context significantly reduce clarity.
Run 1
Code Structure: The small class is logically organized, but numerous unused imports and the undefined JSONTag base class reduce self-contained readability. Nesting: Flat methods and a simple list comprehension are easy to follow. Clarity of intent: Method names clearly indicate list checking and serialization, though PassList and the tag alias require framework context. Code length: The implementation is concise, but the import block is disproportionately long for the shown functionality. Action granularity: Each statement performs one clear action. Reading flow: The class reads naturally, but missing blank lines between imports and the class, and between methods, weaken visual separation.
Run 2
Code Structure: The class is logically organized, but numerous unused imports and an undefined JSONTag base class in the snippet introduce distracting context. Nesting: Methods are flat, with no deeply nested logic. Clarity of intent: check clearly identifies lists, and to_json tags each item; however, PassList and the tag alias require familiarity with the serialization framework. Code length: The implementation is concise, although the import block is disproportionate to the functionality shown. Action granularity: Each statement performs one clear action, and the list comprehension is straightforward. Reading flow: The methods follow a natural validation-then-conversion sequence, but inconsistent blank lines between methods and the unexplained alias slightly interrupt readability.
Run 3
Code Structure: The class cleanly groups list checking and serialization, but numerous unused imports and the missing JSONTag definition weaken the snippet's self-contained organization. Nesting: Methods are flat, with only a straightforward list comprehension. Clarity of intent: Method names, type hints, and isinstance make the purpose mostly clear; the tag alias and serializer dependency require external context. Code length: The implementation is concise, though the import block is disproportionate to the functionality shown. Action granularity: Each statement performs one clear action, and the comprehension remains easy to understand. Reading flow: Execution is easy to follow, but missing spacing between methods and the distant tag alias slightly interrupt the presentation.