Sample
pyint-cc6ba1c10797-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.391 | 0–1; higher is more readable |
| Mi | 0.602 | 0–1; higher is more readable |
| LLOC | 51 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.602 | 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. | 2560.102 | −84.483 |
| Source linesThe number of non-empty source lines. | 125 | +50 |
| 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.411 | −6.617 |
Intercept 8.87 + feature contributions = -32.23 (log-odds).
Score = sigmoid(-32.23) = 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. | 125 | −3.39 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 95 | +2.549 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 95 | −1.759 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 124.873 | +1.336 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 100.976 | +0.825 |
| 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. | 100.96 | −0.611 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.042 | +0.536 |
Intercept 0.07 + feature contributions = -0.444 (log-odds).
Score = sigmoid(-0.444) = 0.391.
| Score | 0.602 |
|---|
| Score | 51 |
|---|
Run 1
The code is well-structured and readable. It uses clear class design with slots, docstrings, and named parameters. The Converter class has a logical flow, and methods are concise with single responsibilities. Nesting is flat, intent is clear, and action granularity is appropriate. Minor issues include the lambda assignments in __init__ which slightly reduce clarity, and the long f-string lines in _fmt_converter_call could be reformatted for better readability.
Run 2
The code is well-structured with clear separation of concerns: imports are organized, the class docstring is thorough, and methods are logically grouped. Nesting is flat—conditional logic in __init__ uses early returns effectively without deep indentation. Intent is explicit: the Converter class wraps callables with optional self/field parameters, and method names like _fmt_converter_call clearly describe their purpose. Code length is appropriate; each method is concise and avoids redundancy (e.g., lambda variants handle parameter combinations cleanly). Action granularity is good—most lines perform one operation, though the conditional lambda assignments pack multiple steps into single lines but remain readable. Reading flow is natural: initialization, state serialization methods, and formatting helpers follow a logical progression. Minor deductions for slightly dense lambda assignments and a few long f-strings, but overall the code is highly readable.
Run 3
The code is well-structured with clear class and method organization. Docstrings explain intent, and the use of __slots__ and lambdas keeps the code concise. Nesting is minimal. However, some methods like _fmt_converter_call contain long f-strings that reduce readability, and the conditional lambda assignments in __init__ could be clearer with a dedicated helper method. Overall, the code is readable but not exemplary.
Run 1
Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, although numerous unrelated imports distract from the excerpt. Nesting: Shallow conditional branches and early returns keep complexity manageable. Clarity of intent: Descriptive method names and detailed documentation explain the converter behavior well; abbreviated names such as ex and rt, placeholder parameters, and dynamically assigned __call__ require additional interpretation. The __getstate__ docstring also omits takes_field despite its inclusion in the returned state. Code length: Generally concise, though repeated flag combinations and long formatted strings add some verbosity. Action granularity: Statements typically perform one action per line, with sensible multiline formatting. Reading flow: Methods follow a natural progression and use whitespace effectively, but runtime callable adaptation and generated call strings modestly increase the reader's cognitive load.
Run 2
Code Structure: Methods are logically separated into initialization, call formatting, and serialization, though many imports are unused in this excerpt. Nesting: Shallow conditional chains and early returns keep complexity manageable. Clarity of intent: Descriptive method names and detailed docstrings explain the converter's purpose; dynamically assigning __call__, placeholder lambda parameters, and abbreviations like ex and rt require extra interpretation. The __getstate__ docstring also omits takes_field despite including it in the returned state. Code length: Generally concise, although repeated condition checks and long generated-call strings add some verbosity. Action granularity: Most lines perform one clear action, with lambdas compactly encapsulating argument adaptation. Reading flow: Initialization proceeds naturally from configuration to callable adaptation and annotations, followed by helper and serialization methods; dynamic behavior slightly interrupts otherwise straightforward reading.
Run 3
Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, although many imports are unused in this excerpt. Nesting: Shallow conditional branches and early returns keep control flow easy to follow. Clarity of intent: Descriptive names and detailed docstrings explain converter behavior well; dynamically assigning __call__, modifying annotations, and placeholder lambda parameters require extra attention. The __getstate__ docstring omits takes_field despite its inclusion in the returned state. Code length: Mostly concise, though repeated flag combinations and generated call strings add some duplication. Action granularity: Statements generally perform one action per line, with clear multiline formatting. Reading flow: Methods follow a natural progression, but abbreviated names such as ex and rt, long formatted strings, and metaprogramming details modestly interrupt readability.