Sample
pyint-91966b1360e8-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.075 | 0–1; higher is more readable |
| Mi | 0.583 | 0–1; higher is more readable |
| LLOC | 72 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.433 | 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. | 5508.226 | −181.771 |
| Source linesThe number of non-empty source lines. | 270 | +108 |
| 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.383 | −6.574 |
Intercept 8.87 + feature contributions = -71.475 (log-odds).
Score = sigmoid(-71.475) = 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. | 271 | −8.559 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 196 | +6.042 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 196 | −4.077 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 269.981 | +3.364 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 104.989 | +0.89 |
| 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. | 104.974 | −0.781 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.042 | +0.539 |
Intercept 0.07 + feature contributions = -2.512 (log-odds).
Score = sigmoid(-2.512) = 0.075.
| Score | 0.583 |
|---|
| Score | 72 |
|---|
Run 1
The code demonstrates strong readability through clear structure (class with logical method grouping), moderate nesting (simple if/else at most 1-2 levels), explicit intent with descriptive comments and docstrings, and appropriate line length. Each line performs a single action, and the reading flow follows a natural top-down progression. The use of helper methods and clear naming conventions enhance comprehension. Some minor inconsistencies exist, such as a stray empty line before raising an error and slight verbosity in the __init__ parameter list, but overall this is highly maintainable code.
Run 2
The code demonstrates moderate readability, benefiting from clear class structure and helpful comments. However, several patterns reduce clarity. The __init__ method is lengthy and contains a mix of validation, caching, and attribute-setting that could be extracted. Magic methods like __getstate__/__setstate__ have dense logic with conditional branching. Some comments are helpful ('Cache this descriptor here'), but others reference future changes ('unused, remove along with other cmp code') without clear context. Variable names like 'ca' and '_CountingAttr' are cryptic. The use of bound_setattr obscures direct assignment, and metadata handling logic repeats across methods. The docstring is thorough but verbose. Nested conditionals in evolve() and __setstate__ create moderate complexity. Alignment with attrs conventions is good, but the code assumes deep familiarity with the library's internals.
Run 3
The code is moderately readable. It has a clear class structure and good documentation, but suffers from several issues. The constructor (__init__) has too many parameters and multiple assignments, making it hard to follow. The from_counting_attr method contains an awkward blank line and some confusing logic. Action granularity is reasonable but there are some multi-action lines. Nesting is relatively flat overall, which is good. The code uses dataclass-like slots and caching appropriately, but the length is excessive for what it does. The intent of each method is generally clear through naming and docstrings, but implementation details like _OBJ_SETATTR.__get__ pattern are cryptic. Type hints are inconsistent - some parameters have them, many don't. The code would benefit from simplification, better parameter organization, and more consistent typing. Overall it's readable enough for experienced Python developers familiar with the attrs library, but not intuitive for newcomers.
Run 1
Code Structure: Well-organized class with distinct methods for initialization, copying, serialization, and internal updates. Nesting: Mostly flat, with shallow conditionals and loops; multiline expressions add some visual complexity. Clarity of intent: Descriptive method names, extensive documentation, and explanatory comments clarify behavior, although internal helpers, descriptor manipulation, and abbreviated names require context. Code length: Generally justified, but repetitive field assignments, lengthy documentation, and the large constructor increase reading effort. Action granularity: Nearly every statement performs one action; tuple unpacking remains understandable. Reading flow: Methods follow a coherent progression, but the long positional constructor call requires matching arguments against the signature and slot order. Awkward line wrapping, a redundant parenthesized exception expression, and minor comment errors slightly disrupt otherwise consistent formatting.
Run 2
Code Structure: Methods are logically separated by responsibility, with documentation explaining invariants and compatibility behavior. Nesting: Mostly flat control flow; conditional expressions and metadata handling add modest complexity. Clarity of intent: Descriptive method names and comments make immutability, copying, and serialization understandable, but internal helpers, abbreviated parameters, and the long positional constructor call require extra context. Code length: Repetitive field assignments and extensive documentation increase length, although much serves a clear purpose; the unused cmp parameter adds clutter. Action granularity: Statements generally perform one action each, making execution easy to follow. Reading flow: Consistent organization supports natural reading, but awkward line wrapping, a redundant pair of parentheses, inconsistent whitespace, and dependence on slot ordering interrupt the flow.
Run 3
Code Structure: Methods are logically separated by responsibility, with documentation explaining immutability, copying, and serialization. Nesting: Generally shallow; conditional expressions and multiline conditions add some complexity without deeply nested control flow. Clarity of intent: Descriptive method names and helpful comments make the purpose clear, although external helpers, descriptor-based assignment, and a long positional constructor call require additional context. Code length: Repeated field assignments and extensive documentation increase length, but most serve a clear purpose; metadata conversion is duplicated. Action granularity: Statements generally perform one action each, making execution easy to follow. Reading flow: Consistent organization supports natural reading, but the slot-order dependency, numerous constructor parameters, awkward formatting in the ValueError statement and pickle compatibility expression, and unused cmp parameter introduce friction.