Sample
pyint-484b3ce3dbae-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.845 | 0–1; higher is more readable |
| Dorn | 0.881 | 0–1; higher is more readable |
| Mi | 0.696 | 0–1; higher is more readable |
| LLOC | 6 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.716 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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.247 | −6.371 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 133.438 | −4.403 |
| Source linesThe number of non-empty source lines. | 9 | +3.6 |
Intercept 8.87 + feature contributions = 1.695 (log-odds).
Score = sigmoid(1.695) = 0.845.
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. | 34.8 | +2.191 |
| 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. | 10 | +0.682 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 9 | −0.426 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 8.778 | −0.287 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.079 | +0.173 |
Intercept 0.07 + feature contributions = 1.998 (log-odds).
Score = sigmoid(1.998) = 0.881.
| Score | 0.696 |
|---|
| Score | 6 |
|---|
Run 1
The code is generally clear and concise. It defines a custom exception `FrozenError` inheriting from `AttributeError`. The structure is logical, and the intent is easy to understand. Nesting is minimal (one class, one method), and line count is low. However, readability is reduced by the blank line after the class declaration, which breaks the natural flow. Additionally, the `msg` attribute is explicitly assigned but not necessary—`AttributeError` already stores the message, making this redundant. The error message 'can't set attribute' is appropriate for a frozen object, but the class could benefit from a docstring explaining its purpose, especially when raised in a larger codebase. Overall, it is readable but could be improved with minor cleanup.
Run 2
The code is clear and concise. It defines a custom exception with a simple structure, minimal nesting, and obvious intent. The use of `from __future__ import annotations` is a good practice. However, there are minor readability issues: a stray blank line after the class declaration, redundant assignment of `self.msg` when `AttributeError` already stores the message, and a slightly unnecessary local variable `msg`. These small redundancies slightly reduce the score, but overall the code remains highly readable.
Run 3
The code is concise and clearly structured. It defines a custom exception with a clear name and a single responsibility. Nesting is minimal, with no deep indentation. Intent is explicit: create a frozen attribute error. The action granularity is appropriate, with one logical action per line. Reading flow is natural from top to bottom. Minor deductions: the extra blank line after the class definition is unnecessary, and the message string could be a class-level constant for reusability, but these are very minor readability concerns.
Run 1
Code Structure: A single exception class with a logically organized initializer. Nesting: Minimal and appropriate. Clarity of intent: The class name, base class, and error message clearly indicate an attribute-mutation error, though storing the message separately is slightly redundant. Code length: Concise, with a potentially unnecessary future import and excess blank space. Action granularity: Each statement performs one clear action. Reading flow: The initializer naturally progresses from defining the message to initializing the base exception and storing the message.
Run 2
Code Structure: Logically organized as a small exception class with a single initializer. Nesting: Shallow and appropriate for a class method. Clarity of intent: Clearly defines an attribute-setting error, although storing the message in self.msg duplicates information already held by the base exception. Code length: Concise, but the unused annotations import and extra blank lines add minor clutter. Action granularity: Each statement performs one action. Reading flow: Natural and easy to follow, with only excessive whitespace interrupting the flow.
Run 3
Code Structure: A straightforward exception class with a logically organized initializer. Nesting: Minimal, limited to the class and method definitions. Clarity of intent: The class name, AttributeError inheritance, and error message clearly indicate an error for prohibited attribute assignment. Code length: Concise, though storing the message in self.msg may be redundant, and the future import appears unnecessary in this snippet. Action granularity: Each statement performs one clear action. Reading flow: Natural and easy to follow, but extra blank lines inside the class create distracting whitespace.