Sample
pyint-1710f28428ed-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.346 | 0–1; higher is more readable |
| Mi | 0.738 | 0–1; higher is more readable |
| LLOC | 58 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.48 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 3811.44 | −125.778 |
| Source linesThe number of non-empty source lines. | 195 | +78 |
| 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.037 | −6.056 |
Intercept 8.87 + feature contributions = -44.964 (log-odds).
Score = sigmoid(-44.964) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 196 | −5.903 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 168 | +5.074 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 168 | −3.434 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 194.987 | +2.316 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.053 | +0.424 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 75.342 | +0.411 |
| 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. | 76.964 | +0.405 |
Intercept 0.07 + feature contributions = -0.638 (log-odds).
Score = sigmoid(-0.638) = 0.346.
| Score | 0.738 |
|---|
| Score | 58 |
|---|
Run 1
The code is generally well-structured and readable. It uses clear naming conventions, docstrings, and type hints. The class definition and methods are logically organized, and the use of `__slots__` improves clarity. However, there are some readability challenges. The `__attrs_attrs__` tuple construction is complex and visually dense, mixing comprehensions with explicit `Attribute` calls. The long parameter lists in `__init__` and `Attribute` reduce readability. The code is mostly flat with minimal deep nesting, and each line tends to perform one action, which aids comprehension. The reading flow is mostly natural, but the large block of attribute definitions could be broken down for better scannability. Overall, it is readable but could be improved by simplifying the meta-attribute construction and reducing verbosity in parameter handling.
Run 2
The code is generally structured, with clear sections for imports, class definition, slots, and methods. It uses typing and docstrings. However, readability is hampered in places: the __attrs_attrs__ assignment uses a large tuple/generator mix that is visually dense. The __init__ method takes many positional parameters, making intent and usage harder to follow at a glance. Some nested expressions, like the lambda in converter(), slightly reduce clarity. Positive aspects include flat nesting, one action per line in most methods, and clear method names. Overall, the code is maintainable but could be more approachable with better parameter organization and less dense attribute declarations.
Run 3
The code is generally readable and well-structured, with clear class organization and reasonable use of docstrings. It uses `__slots__` and tuple-based `__attrs_attrs__` definitions, which are common in this codebase but add some cognitive overhead. The `__attrs_attrs__` definition is long and contains repetitive `Attribute(...)` calls, which reduces readability. However, the methods are concise, each performing a single logical action, and the nesting is flat. The `converter` method has a slightly complex lambda, but it is understandable given the context. Overall, the code is maintainable but could benefit from reducing repetition in the attribute definitions.
Run 1
Code Structure: The class is logically organized into slot declarations, attribute metadata, initialization, and decorator methods. Nesting: Control flow is shallow, with simple conditionals; the metadata comprehension adds modest complexity. Clarity of intent: Descriptive names and focused docstrings explain ordering and decorator behavior, although external helpers and numerous configuration fields require library context. Code length: Explicit metadata definitions and a long constructor are somewhat repetitive but easy to inspect. Action granularity: Statements generally perform one action per line, with clearly separated assignments. Reading flow: Methods follow a consistent pattern, and spacing supports scanning. The lengthy class-level metadata and constructor delay reaching the core behavior, while the converter lambda requires closer reading.
Run 2
Code Structure: The class is logically organized into metadata, initialization, and focused decorator methods, although the large metadata declaration dominates the opening. Nesting: Control flow is shallow, with simple conditionals; the nested tuple comprehension adds modest visual complexity. Clarity of intent: Descriptive names and method docstrings explain attribute ordering and decorator behavior well. External symbols and the converter lambda require some library context. Code length: Methods are concise, but repeated Attribute arguments, the lengthy constructor signature, and mechanical assignments make the class verbose. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Consistent formatting and straightforward methods support natural reading, though extensive imports and metadata delay the main behavior. Overall, readable and maintainable despite some boilerplate and framework-specific complexity.
Run 3
Code Structure: The class is logically organized into attribute declarations, initialization, and focused decorator methods, although the extensive imports distract from this excerpt. Nesting: Control flow is shallow; only the attribute-construction comprehension adds visual complexity. Clarity of intent: Descriptive method names and useful docstrings explain ordering, validation, defaults, and conversion. External helpers and sentinel values require library context, while names such as cmp and meth are less explicit. Code length: The constructor and repeated Attribute configuration are verbose but largely justified by the data model; some configuration could be factored out. Action granularity: Statements generally perform one action per line, making assignments and state changes easy to follow. Reading flow: Consistent formatting and straightforward method bodies support natural reading, though the large class-level metadata block delays reaching the main behavior.