Sample
pyint-1068ff3e3ef5-SRC
Unmodified source class
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 | 15.33 | 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 has a clear purpose with good docstrings explaining the non-obvious MRO and error construction logic. However, several issues hurt readability: the inheritance order is counterintuitive and requires explanation to understand. The __init__ method relies on side effects of assigning self.args between parent calls, which is subtle and fragile. Method names like __reduce__ are not self-documenting without domain knowledge. The nested exception class hierarchy adds cognitive overhead. Some lines are unnecessarily long (exceeding 79 characters). The code is concise but at the cost of clarity - a reader must understand Python's MRO, pickling protocol, and error class internals. The docstrings help but indicate the code itself is not naturally readable. Structure is acceptable but the tricky initialization sequence makes maintenance risky.
Run 3
The code is well-structured with clear separation of concerns through multiple inheritance. It maintains a flat nesting structure with no deep conditionals. Naming is descriptive and docstrings effectively explain the non-obvious parts, particularly the inheritance and pickling behavior. The class body is concise, containing only two methods. Each method performs a single logical action per line, with the __init__ method making its two-part initialization explicit. The reading flow is natural: construct, then handle serialization. Minor deductions: the multiple inheritance line could benefit from a brief comment, and the __reduce__ docstring is somewhat dense. Overall, the code is highly readable and maintainable.
Run 1
Code Structure: Imports and a focused exception class are logically organized, though InvalidJSONError is not defined or imported in the snippet and two imports are unused. Nesting: Minimal nesting makes both methods easy to follow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the subtle initialization and pickling behavior; multiple inheritance requires some background knowledge. Code length: The implementation is concise, although the explanatory docstrings are somewhat verbose. Action granularity: Each statement performs one clear action. Reading flow: Initialization followed by serialization support is natural, with explicit base-class calls making the execution sequence clear.
Run 2
Code Structure: The exception class logically groups initialization and pickling behavior, although InvalidJSONError is not defined or imported in the snippet and two imports are unused. Nesting: Methods are flat, with no branching or deeply nested blocks. Clarity of intent: Descriptive names, type annotations, and docstrings explain the otherwise subtle multiple-inheritance behavior. Code length: Implementation is concise; the docstrings are somewhat verbose but provide useful context. Action granularity: Each executable line performs one clear action. Reading flow: Imports, class declaration, initialization, and serialization follow a natural sequence, though understanding the parent classes and method resolution order requires external context.
Run 3
Code Structure: The exception class is logically organized, with initialization followed by serialization behavior, though InvalidJSONError is not defined or imported in the snippet and two imports are unused. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names, type annotations, and docstrings explain the unusual multiple-inheritance initialization and pickling requirements. Code length: The implementation is concise, although the docstrings are somewhat wordy and contain minor grammatical issues. Action granularity: Each statement performs one clear action. Reading flow: Imports, class declaration, constructor, and __reduce__ follow a natural sequence; understanding the inheritance interactions requires some familiarity with exception internals.