Sample
pyint-3cfaaceb42a0-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.988 | 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.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 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.447 | −6.671 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 140.182 | −4.626 |
Intercept 8.87 + feature contributions = 4.373 (log-odds).
Score = sigmoid(4.373) = 0.988.
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. Structure is logical and well-organized: a custom exception class with a clear docstring, proper inheritance from AttributeError, and a straightforward __init__ method. Nesting is minimal and flat. Intent is unambiguous—creating a frozen attribute error mirroring namedtuple behavior. Length is concise with no unnecessary code. Each action (creating message, calling super, assigning attribute) is on its own line, following clean action granularity. Reading flow is natural, from class definition to docstring to initialization. Minor deductions: the 'msg' attribute assignment is slightly redundant since the message is already stored by the base exception, and the docstring could be trimmed, but these are trivial and don't hinder comprehension.
Run 2
The code is highly readable. It defines a custom exception with a clear, specific purpose. The class structure is logical, with a single constructor that sets an explicit error message. Nesting is minimal, limited to the class and method definitions. Intent is unambiguous: the docstring fully explains the class's role and versioning. The code is concise, with no redundant operations. Action granularity is appropriate—message creation, super().__init__ call, and attribute assignment are each on separate lines. The reading flow is natural, guiding the reader from class definition to implementation details. Minor deductions: the self.msg assignment slightly duplicates information already passed to the parent class, but this is a minor design choice that doesn't significantly impact clarity.
Run 3
The code is well-structured and readable: a single class with a clear purpose, a docstring explaining behavior, minimal nesting, and concise method implementation. The intent—to define a custom frozen attribute error—is unambiguous. Action granularity is appropriate with one meaningful statement per line. Minor deductions: the docstring is relatively long for the simple logic, the `msg` is duplicated in both `super().__init__` and `self.msg` without clear need, and reading flow is slightly interrupted by the verbose docstring before the constructor. Overall, the code is clear and maintainable, but the length and duplication slightly reduce readability.
Run 1
Code Structure: Imports, class documentation, and initialization are logically organized. Nesting: Minimal, with only a class and its method. Clarity of intent: The descriptive class name, AttributeError inheritance, and docstring clearly explain the exception's purpose; the opening docstring sentence has a minor grammatical issue. Code length: Short and focused, though storing the message in self.msg appears slightly redundant without additional context. Action granularity: Each statement performs one action. Reading flow: Natural top-to-bottom progression from definition and explanation to implementation.
Run 2
Code Structure: A single, well-organized exception class with a focused initializer. Nesting: Minimal, limited to the class and method definitions. Clarity of intent: The class name, inheritance, and docstring clearly communicate its purpose, though the docstring's opening sentence is grammatically awkward. Code length: Compact, with documentation proportionate to the implementation; storing the message separately adds a small amount of extra code. Action granularity: Each statement performs one clear action. Reading flow: Natural progression from import to class documentation to initialization, with appropriate whitespace.
Run 3
Code Structure: A single, logically organized exception class with documentation followed by initialization. Nesting: Minimal, limited to the class and its constructor. Clarity of intent: The class name, AttributeError inheritance, docstring, and error message clearly communicate its purpose, although the docstring's opening sentence is grammatically awkward. Code length: Concise, with no unnecessary implementation complexity; the documentation is proportionate. Action granularity: Each statement performs one action on its own line. Reading flow: Natural top-to-bottom progression from import to class documentation to initialization. Minor spacing and wording improvements would polish readability.