Sample
Inline all eligible single-use intermediate local variables
| 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 | 17 | 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 |
Loading feature diagnosis…
| 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 | 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 |
|---|
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.
The code is highly readable. It has a clear, single-purpose class with a logical structure, minimal nesting, and concise implementation. The docstring effectively explains intent and context, while method and variable names are explicit. Action granularity is appropriate, with only the necessary assignments and super() call. Reading flow is natural, following a clear top-to-bottom progression. Minor deductions: the redundant instance attribute `self.msg` duplicates the message already stored in the exception's args, slightly reducing conciseness, and the class docstring could be marginally shorter without losing clarity. Overall, excellent readability.
The code is clear, well-structured, and concise. It defines a custom exception with a single-purpose, flat structure. Class and method definitions are minimal and logical. The docstring clearly explains intent, versioning, and design rationale. Variable naming is straightforward, and there is no unnecessary nesting or repetition. Minor point: `self.msg = msg` is slightly redundant since the message is already stored in `args`, but it is a harmless explicit accessor. Overall, very readable.
Code Structure: The exception class is logically organized, with documentation followed by a short initializer. Nesting: Minimal nesting makes the code easy to follow. 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; storing the message in self.msg adds slight redundancy but may serve callers. Action granularity: Each statement performs a single clear action. Reading flow: Natural progression from the class description to message creation, superclass initialization, and attribute assignment.
Code Structure: Imports, class documentation, and initialization are logically organized. Nesting: Minimal, with only a class and its constructor. Clarity of intent: The class name, AttributeError inheritance, and docstring clearly communicate the purpose; minor grammatical errors in the docstring slightly reduce polish. Code length: Concise, although storing the message in both the exception and self.msg appears potentially redundant. Action granularity: Each statement performs one action. Reading flow: Natural top-to-bottom progression from context to implementation, with clear spacing and straightforward message initialization.
Code Structure: A single, logically organized exception class with a focused initializer. Nesting: Minimal, limited to the class and method. Clarity of intent: The descriptive class name, docstring, and explicit error message clearly communicate its purpose; minor grammatical issues in the docstring slightly reduce polish. Code length: Concise, with documentation proportionate to the functionality, though the future import appears unnecessary in this snippet. Action granularity: Each statement performs one clear action. Reading flow: Natural progression from import to class documentation to initialization, with consistent indentation and useful spacing.