Sample
pyint-6eba79d842fb-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.986 | 0–1; higher is more readable |
| Dorn | 0.837 | 0–1; higher is more readable |
| Mi | 0.819 | 0–1; higher is more readable |
| LLOC | 7 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.701 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 17 | +6.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.475 | −6.713 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 142.624 | −4.707 |
Intercept 8.87 + feature contributions = 4.251 (log-odds).
Score = sigmoid(4.251) = 0.986.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.033 | +0.622 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 9 | −0.426 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 18 | +0.399 |
| 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. | 73.556 | +0.382 |
| 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. | 78 | +0.361 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 16.873 | −0.174 |
Intercept 0.07 + feature contributions = 1.633 (log-odds).
Score = sigmoid(1.633) = 0.837.
| Score | 0.819 |
|---|
| Score | 7 |
|---|
Run 1
The code is highly readable. It has a clear, single-purpose class with a logical structure: docstring, then a simple __init__ method. The nesting is minimal (one level), and the intent is explicit—a custom frozen attribute error mirroring namedtuple behavior. The action granularity is appropriate, with one operation per line, though the assignment of self.msg duplicates the parent's message and could be seen as slightly redundant. Overall, the flow is natural and easy to follow.
Run 2
The code is clear and well-structured. The class definition is concise, with a focused docstring explaining purpose and behavior. Nesting is minimal, and intent of the custom FrozenError is immediately understandable. One minor readability improvement would be separating the super().__init__ call and the self.msg assignment onto different logical blocks, but both are on separate lines as well. The use of a separate variable 'key' is slightly verbose for such a short string, but it aids clarity. Overall, the code is easy to read and maintain.
Run 3
The code is well-structured with a clear single-purpose class extending AttributeError. The docstring thoroughly explains intent and version compatibility. Nesting is minimal. The __init__ method is concise, using a local variable to avoid duplication in both the super().__init__ call and the msg attribute assignment. One minor issue is the slight redundancy of storing msg separately when AttributeError already carries the message, but this may be a deliberate design choice for external access. Indentation and spacing are clean, making the code highly readable.
Run 1
Code Structure: Clearly organized into a custom exception class, its documentation, and a short initializer. Nesting: Minimal, with only the class and method levels. Clarity of intent: The class name, AttributeError inheritance, and docstring clearly communicate an immutable-attribute modification error; minor grammatical issues in the docstring slightly reduce clarity. Code length: Concise, with useful documentation, although the future import is unnecessary in this snippet. Action granularity: Each statement performs one action. Reading flow: Natural progression from purpose to initialization, with straightforward assignment and superclass initialization. The variable name 'key' is less descriptive than 'message', but does not significantly impede understanding.
Run 2
Code Structure: A single, logically organized exception class with documentation followed by initialization. Nesting: Minimal, limited to the class and its method. Clarity of intent: The class name, AttributeError inheritance, and docstring clearly communicate its purpose; the local name 'key' is less descriptive than 'message'. Code length: Concise, though the docstring is relatively long for the small implementation. Action granularity: Each statement performs one clear action. Reading flow: Natural top-to-bottom progression from purpose to implementation, with consistent formatting. Minor grammatical awkwardness in the docstring slightly reduces polish.
Run 3
Code Structure: The exception class is logically organized, with documentation followed by a short initializer. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, AttributeError inheritance, and docstring clearly communicate its purpose, though the docstring's opening sentence is grammatically awkward. Code length: Concise overall; the documentation is proportionate, while the future import appears unnecessary in this snippet. Action granularity: Each statement performs one action. Reading flow: Execution proceeds naturally from defining the message to initializing the parent exception and storing the message. The variable name 'key' is less descriptive than 'message', slightly reducing readability.