Sample
pyint-817e301ecd80-I02
Shorten method, parameter, and local names without collisions
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 | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.762 | 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.469 | −6.703 |
| 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.261 (log-odds).
Score = sigmoid(4.261) = 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.624 |
| 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.797 | −0.175 |
Intercept 0.07 + feature contributions = 1.634 (log-odds).
Score = sigmoid(1.634) = 0.837.
| Score | 0.819 |
|---|
| Score | 7 |
|---|
Run 1
The code has a clear structure and purpose, with a well-defined class and meaningful docstring. It avoids deep nesting and keeps actions straightforward. However, the __init__ method has redundant variable naming (msg2) that reflects unclear intent, and the self.msg attribute is unnecessary since the message is already passed to super().__init__. The docstring could be more concise, though it provides useful context. Overall, the code is readable but has minor clarity issues that prevent a higher score.
Run 2
The code is highly readable. It defines a custom exception with a clear class name (FrozenError), logical inheritance from AttributeError, and a concise docstring explaining purpose and version. The __init__ method is flat, has one action per line, and follows a natural flow. Minor improvements: the variable name 'msg2' is slightly ambiguous (why '2'?), and the instance attribute self.msg is redundant since the message is already stored in args. These small issues aside, the code is well-structured and easy to understand.
Run 3
The code is highly readable. It defines a custom exception class with a clear purpose, well-documented with a docstring explaining behavior and version. The constructor is straightforward, initializing a message and calling super. Minor points: using 'msg2' instead of 'msg' is slightly odd, and the message could be assigned directly in super().__init__ to avoid duplication, but overall the structure is logical, nesting is flat, and intent is clear.
Run 1
Code Structure: The import, exception class, docstring, and initializer are logically organized. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: The class name, AttributeError inheritance, and documentation clearly identify an exception for immutable attribute modification; however, the awkward docstring grammar and variable name 'msg2' slightly reduce clarity. Code length: The implementation is concise, though the temporary message variable could have a clearer name and the future import is unnecessary in this snippet. Action granularity: Each executable line performs one action. Reading flow: Execution proceeds naturally from defining the message to initializing the exception and storing the message.
Run 2
Code Structure: A single, logically organized exception class with documentation followed by initialization. Nesting: Minimal, with only the class and method levels. Clarity of intent: The class name, inheritance, and docstring clearly describe its purpose, although the awkward docstring wording and variable name 'msg2' slightly reduce clarity. Code length: Concise overall; the temporary variable and stored message add minor verbosity, while the compatibility explanation is useful. Action granularity: Each statement performs one action on its own line. Reading flow: Natural top-to-bottom progression from import to class documentation to constructor, with appropriate spacing.
Run 3
Code Structure: Clearly organized as a small exception class with documentation followed by its initializer. Nesting: Minimal, with only standard class and method indentation. Clarity of intent: The class name, inheritance, and docstring clearly convey the purpose, although the docstring's opening sentence is awkward and 'msg2' is an unnecessarily vague variable name. Code length: Concise overall; the temporary variable and stored message add slight overhead but are understandable. Action granularity: Each statement performs one action, making the initializer easy to scan. Reading flow: Natural top-to-bottom progression from import to class documentation to implementation, with appropriate whitespace.