Sample
pyint-d8cdbb59806a-I12
Inline all eligible single-use intermediate local variables
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.33 | 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 generally well-structured with clear class and method boundaries, docstrings, and consistent use of type hints. The Converter class has a focused purpose and the methods are mostly single-purpose. However, readability is reduced by the dynamic assignment of __call__ via lambdas in __init__, which obscures the call behavior and makes it harder to trace execution. The _fmt_converter_call method contains somewhat long f-strings with multiple arguments, but remains understandable. Nesting is minimal and the reading flow is mostly natural. The code is concise but not overly compressed, with reasonable line lengths and use of blank lines. Overall, it is quite readable, though the lambda-based __call__ assignment and one long f-string slightly detract from clarity.
Run 3
The code is generally well-structured with clear class organization, imports, docstrings, and type hints. The Converter class uses slots and a clean __init__ that assigns responsibilities logically. Nesting is minimal and readable. The lambda-based __call__ assignments are concise but somewhat subtle—readers must track conditional logic across multiple branches to determine which call signature is active. The _fmt_converter_call method uses somewhat long f-strings and repeated conditional checks, which slightly impacts scanning and readability. Action granularity is mostly good, with one main action per line, though a few long lines break this. Naming is consistent and intent is mostly clear. The use of __getstate__/__setstate__ and _AnnotationExtractor adds abstraction that may require domain knowledge but is documented. Overall, readability is high but slightly reduced by conditional lambda assignments and long f-string expressions.
Run 1
Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, though the extensive imports distract from the focused snippet. Nesting: Conditional branches are shallow, and early returns keep formatting logic flat. Clarity of intent: Descriptive method names and detailed docstrings explain converter behavior well; abbreviated names such as ex and rt, placeholder lambda parameters, and dynamic __call__ assignment require closer reading. Code length: Methods are reasonably concise, although argument-selection logic is repeated and some formatted strings are long. Action granularity: Statements generally perform one action per line, with multiline calls aiding readability. Reading flow: The progression from setup to helper methods and state handling is natural. Minor distractions include the unused _global_name slot and a __getstate__ docstring that omits takes_field despite its inclusion in the returned dictionary.
Run 2
Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, though many imports are unused in this excerpt. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive method names and detailed docstrings explain the converter behavior well; abbreviated names such as ex and rt, placeholder lambda parameters, and dynamic __call__ assignment require extra interpretation. Code length: Mostly concise, but repeated flag checks and long formatted strings add some verbosity. Action granularity: Statements generally perform one action per line, with multiline lambdas remaining readable. Reading flow: Methods follow a natural progression, although annotation manipulation and generated call strings introduce complexity. The __getstate__ docstring omits takes_field despite its inclusion in the returned state.
Run 3
Code Structure: The class is logically organized into initialization, converter-call formatting, and serialization methods, although many imports are unused in this excerpt. Nesting: Shallow conditional branches and early returns keep complexity manageable. Clarity of intent: Descriptive method names and detailed docstrings explain the converter options well; dynamic __call__ assignment, placeholder lambda arguments, and abbreviated names such as ex and rt require extra interpretation. The __getstate__ docstring also omits takes_field despite its inclusion in the returned state. Code length: Methods are reasonably concise, though repeated flag checks and generated-call expressions introduce some duplication. Action granularity: Statements generally perform one action per line, with readable multiline formatting. Reading flow: The progression from setup to invocation formatting to state handling is natural; long f-strings and dynamic annotation manipulation slightly interrupt readability.