Sample
pyint-af64cc768261-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.161 | 0–1; higher is more readable |
| Mi | 0.501 | 0–1; higher is more readable |
| LLOC | 46 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.56 | 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. | 2500.751 | −82.525 |
| Source linesThe number of non-empty source lines. | 95 | +38 |
| 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.412 | −6.618 |
Intercept 8.87 + feature contributions = -42.273 (log-odds).
Score = sigmoid(-42.273) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 95 | +2.549 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 96 | −2.363 |
| 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. | 94.843 | +0.916 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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.938 | −0.61 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.061 | +0.354 |
Intercept 0.07 + feature contributions = -1.648 (log-odds).
Score = sigmoid(-1.648) = 0.161.
| Score | 0.501 |
|---|
| Score | 46 |
|---|
Run 1
The code is generally well-structured with clear class boundaries and type hints. However, it has readability issues: the conditional lambda assignments in __init__ create branching logic that's slightly hard to follow, and the if/elif chain could be more explicit. The empty first line after class definition and use of dunder slots is standard but adds little. Method names clearly indicate intent (e.g., _fmt_converter_call), but some logic like _AnnotationExtractor usage isn't obvious without external context. The code is concise and avoids deep nesting, but the lambda assignments with placeholder underscores reduce clarity of parameter roles. Overall, it's readable but could be improved with clearer conditional structure and more descriptive parameter names than `__` placeholders.
Run 2
The code is relatively readable due to its clean structure, flat conditional logic, and clear purpose for each method. The class has a logical organization with `__slots__`, `__init__`, helper methods, and state serialization methods. Nesting is shallow; the conditional branches in `__init__` are easy to follow. Action granularity is reasonable, with one main operation per line in most cases. However, the use of lambda assignments to `self.__call__` is slightly non-obvious and reduces clarity of intent. The `_fmt_converter_call` method has long f-strings that are somewhat hard to parse, and the underscores in `__call__` parameters are cryptic. Overall, code is concise but could benefit from clearer naming and minor refactoring for improved readability.
Run 3
The code is generally readable with clear class structure and logical organization. It uses type hints and docstrings sparingly. However, there are some issues: the lambda assignments in __init__ create complex one-liners that reduce clarity of intent, and the conditional branching for takes_self/takes_field, while flat, could be more explicit. The __slots__ declaration with dunder names is slightly confusing. The _fmt_converter_call method has repetitive conditionals and long f-string lines exceeding typical line length. The action granularity is mostly one action per line, but some lambdas pack multiple operations. Import section is well-organized. Overall, the code is maintainable but could benefit from breaking down complex lambda assignments and simplifying the converter call formatting logic.
Run 1
Code Structure: The class is logically organized into initialization, call formatting, and serialization helpers, though the many unrelated imports distract from the excerpt. Nesting: Control flow is shallow, with straightforward conditional branches and early returns. Clarity of intent: Descriptive method names and flags communicate converter behavior, but dynamic __call__ assignment, annotation mutation, abbreviated names such as ex and rt, and placeholder lambda parameters require extra interpretation. Code length: Methods are reasonably concise, although repeated flag checks and formatted call strings add some duplication. Action granularity: Most lines perform one action; multiline expressions are appropriately separated. Reading flow: The method sequence is natural and branches are easy to follow, but excessive blank lines, long formatted strings, and the absence of explanatory documentation interrupt an otherwise readable implementation.
Run 2
Code Structure: Methods are logically separated into initialization, call formatting, and serialization, although many imports are unused in this snippet. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Descriptive method and flag names communicate converter behavior, but missing documentation, abbreviated names such as ex and rt, placeholder lambda parameters, and dynamic annotation updates require extra interpretation. Code length: Generally concise, though repeated flag combinations and long formatting expressions add some redundancy. Action granularity: Most lines perform a single action; multiline lambdas remain understandable. Reading flow: The class progresses naturally from setup to helpers and state handling, but excessive blank whitespace and long generated-call strings interrupt scanning.
Run 3
Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, although many imports are unused in the excerpt. Nesting: Conditional branches remain shallow and easy to follow. Clarity of intent: Descriptive method and flag names communicate converter behavior, but missing documentation, abbreviated variables such as ex and rt, and placeholder lambda parameters reduce clarity. Code length: Mostly concise, though repeated flag combinations and generated-call expressions add some redundancy; excessive blank lines also distract. Action granularity: Statements generally perform one action each, with compact lambdas remaining understandable. Reading flow: Methods follow a natural progression, but dynamically assigning __call__, modifying annotations, and constructing executable call strings require extra attention.