Sample
pyint-ad505c3c1397-I13
Lower every eligible synchronous for loop to a while loop
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.1 | 0–1; higher is more readable |
| Mi | 0.583 | 0–1; higher is more readable |
| LLOC | 77 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.67 | 0–20; mean of three runs |
| BTTF | 0.497 | 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. | 5820.933 | −192.091 |
| Source linesThe number of non-empty source lines. | 275 | +110 |
| 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.382 | −6.573 |
Intercept 8.87 + feature contributions = -79.793 (log-odds).
Score = sigmoid(-79.793) = 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. | 276 | −8.736 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 201 | +6.215 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 201 | −4.191 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 274.967 | +3.434 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.957 | +0.663 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.042 | +0.531 |
| 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. | 90.946 | −0.187 |
Intercept 0.07 + feature contributions = -2.201 (log-odds).
Score = sigmoid(-2.201) = 0.1.
| Score | 0.583 |
|---|
| Score | 77 |
|---|
Run 1
The code demonstrates good documentation and logical class structure, but has significant readability issues. (1) Structure: clear class organization with well-documented slots, though import statements are scattered across multiple lines. (2) Nesting: mostly flat, but `_setattrs` uses an unnecessarily manual while-loop with try/except instead of a simple for-loop, creating convoluted logic. (3) Clarity of intent: docstrings are excellent, but the weird `__import__('builtins').iter/next` pattern obscures intent when `iter()` and `next()` builtins would work. (4) Length: verbose but justified by complex initialization logic; the manual iterator loop adds unnecessary length. (5) Action granularity: mostly one action per line, though the metadata handling mixes conditionals inline. (6) Reading flow: natural top-to-bottom flow in `__init__`, but jarring in `_setattrs` due to the unnatural builtin import workaround and while-loop structure.
Run 2
The code has clear intent and good documentation, especially the Attribute class docstring and __slots__ organization. However, readability suffers from several issues: the _setattrs method uses unnecessarily obscure constructs like __import__('builtins') and manual while/next iteration instead of a simple for loop; the __init__ method has many parameters and repetitive bound_setattr calls that could be simplified; some comments reference legacy behavior (e.g., 'cmp: unused'). While the overall structure is logical with clear separation of concerns, the action granularity is inconsistent, and the nested conditional logic in evolve() adds complexity. The code is moderately readable but would benefit from simplification and modern Python idioms.
Run 3
The code is severely compromised by deliberate obfuscation in the `_setattrs` method. The use of `__import__('builtins').iter()` and `__import__('builtins').next()` with a manual `while True`/`try/except StopIteration` loop is unnecessarily cryptic and replaces what should be a simple `for` loop. This single method destroys readability across multiple criteria: it obscures intent, violates one-action-per-line by embedding imports in expressions, breaks natural reading flow, and adds unnecessary length. While the rest of the file shows generally good structure with clear docstrings, reasonable nesting, and organized imports, the `_setattrs` method is so egregious that it drags the overall score down dramatically. The contrast between the otherwise professional quality and this one terrible method suggests intentional obfuscation, making the code unreliable and unreadable in practice.
Run 1
Code Structure: The class is logically organized into initialization, conversion, copying, serialization, and internal mutation methods. Nesting: Most methods are shallow, although _setattrs introduces an unnecessary while/try/except structure instead of a simple for loop. Clarity of intent: Descriptive method names, extensive documentation, and explanatory comments help, but dynamic builtins imports, positional constructor arguments, and order-dependent slots obscure details. Code length: Repeated field assignments and lengthy documentation increase scanning effort; the manual iteration adds avoidable verbosity. Action granularity: Most statements perform one clear action, though tuple unpacking and compound conditional expressions require additional attention. Reading flow: Method boundaries and consistent formatting generally support natural reading, but the long constructor, dense compatibility logic, awkward line wrapping in __setstate__, and inconsistent loopIterator naming interrupt it.
Run 2
Code Structure: The class is logically organized into initialization, construction, copying, and serialization methods, though numerous unrelated imports add clutter. Nesting: Mostly shallow; metadata handling and the manual iterator loop introduce modest complexity. Clarity of intent: Descriptive method names, documentation, and comments explain immutability and compatibility behavior. However, the large positional constructor call, external helpers, and repeated dynamic builtins imports obscure details. Code length: Extensive documentation and repetitive field assignments are largely justified, but _setattrs is unnecessarily verbose compared with a standard for loop. Action granularity: Statements generally perform one action each, making operations easy to track. Reading flow: Method boundaries and consistent formatting support natural reading, but order-dependent slots, long argument lists, and awkwardly wrapped alias inference require cross-referencing and interrupt the flow.
Run 3
Code Structure: The class is logically organized into initialization, copying, serialization, and attribute-setting methods, although many imports are irrelevant to this excerpt. Nesting: Most logic is shallow; the manual iterator loop adds avoidable nesting. Clarity of intent: Descriptive method names, documentation, and comments explain immutability and compatibility behavior. However, the long positional constructor call and reliance on slot ordering obscure field correspondence. Code length: Repetitive assignments are understandable, but extensive documentation and the unnecessarily expanded iteration increase reading effort. Action granularity: Statements generally perform one action per line, with multiline expressions formatted clearly. Reading flow: Related operations are grouped naturally, but repeated dynamic builtins imports, the unconventional loopIterator name, and awkward wrapping in pickle migration logic interrupt the flow. Overall, readable and well documented, with localized complexity and verbosity.