Sample
pyint-1e7073676e63-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.007 | 0–1; higher is more readable |
| Dorn | 0.846 | 0–1; higher is more readable |
| Mi | 0.401 | 0–1; higher is more readable |
| LLOC | 13 | 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.727 | 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. | 533.839 | −17.617 |
| Source linesThe number of non-empty source lines. | 27 | +10.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.69 | −7.034 |
Intercept 8.87 + feature contributions = -4.981 (log-odds).
Score = sigmoid(-4.981) = 0.007.
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. | 71.964 | +0.617 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.039 | +0.559 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 61.857 | +0.194 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 16 | −0.184 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 27 | +0.08 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 26.849 | −0.035 |
Intercept 0.07 + feature contributions = 1.7 (log-odds).
Score = sigmoid(1.7) = 0.846.
| Score | 0.401 |
|---|
| Score | 13 |
|---|
Run 1
The code is well-structured with clear class definition, logical MRO handling, and explicit intent through docstrings. It maintains flat nesting, concise methods, and one action per line. Minor readability trade-offs include slightly complex inheritance (necessary for the use case) and somewhat dense docstrings, but overall it is highly readable and maintainable.
Run 2
The code is generally well-structured and readable. It has a clear class hierarchy, concise docstrings explaining non-obvious behavior, and follows good practices like explicit type annotations. Nesting is minimal (one class with two methods), and each action is on its own line. The __init__ method has a clear sequential flow, constructing one parent from args then another from those results. The __reduce__ method is short with a clear purpose. Minor deductions: the multiple inheritance order may require careful reading, and the __init__ logic, while documented, is somewhat subtle. Overall, the code is concise, well-commented where needed, and easy to follow for someone familiar with Python MRO and error class hierarchies.
Run 3
The code is well-structured and readable. The class definition is concise, with a clear multiple inheritance pattern and purposeful method overrides. Docstrings are thorough and explain the non-obvious reasoning behind the method implementations, which significantly enhances clarity. Nesting is minimal, and each method focuses on a single action, maintaining good action granularity. The logic in __init__ is slightly complex but is well-documented. Variable names are descriptive, and the overall length is appropriate. The only minor drawback is the slight complexity in understanding the multiple inheritance behavior without documentation, but the provided docstrings mitigate this effectively.
Run 1
Code Structure: The class cleanly groups initialization and pickling behavior, though InvalidJSONError is not defined or imported in the snippet, and two imports are unused. Nesting: There is no nested control flow, making the methods easy to scan. Clarity of intent: Descriptive names, type annotations, and docstrings explain the otherwise subtle multiple-inheritance behavior. Minor grammatical errors slightly reduce polish. Code length: Implementation is concise; the longer docstrings provide useful context rather than unnecessary repetition. Action granularity: Each statement performs a single clear action. Reading flow: Imports, class declaration, initialization, and serialization follow a natural order, although understanding the inheritance relationships requires context outside the snippet.
Run 2
Code Structure: Imports and a focused exception class are logically organized, though InvalidJSONError is not defined or imported in the snippet, and two imports appear unused. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Type annotations and docstrings explain the unusual initialization and pickling behavior, although understanding it requires familiarity with multiple inheritance and method resolution order. Code length: The implementation is concise; the docstrings are somewhat lengthy but provide useful context. Action granularity: Each executable line performs one clear action. Reading flow: Initialization followed by serialization support is natural, with explicit base-class calls making execution straightforward. Minor grammatical issues in the documentation slightly reduce polish.
Run 3
Code Structure: The class is logically organized into initialization and pickling behavior, though InvalidJSONError is not defined or imported in the snippet and two imports are unused. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Type hints and docstrings explain the multiple-inheritance initialization and serialization requirements, although understanding them requires familiarity with exception inheritance and MRO. Code length: Implementation is concise, but the explanatory docstrings are somewhat wordy. Action granularity: Each statement performs one clear action. Reading flow: Imports, class declaration, initialization, and serialization follow a natural order; the missing base-class context and minor documentation wording issues slightly interrupt comprehension.