Sample
pyint-03e50fd988ae-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.919 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 38 | 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.581 | 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. | 2524.999 | −83.325 |
| Source linesThe number of non-empty source lines. | 98 | +39.2 |
| 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.658 | −6.987 |
Intercept 8.87 + feature contributions = -42.242 (log-odds).
Score = sigmoid(-42.242) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 94 | +2.514 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 99 | −2.469 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 97.875 | +0.958 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.99 | +0.599 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.058 | +0.379 |
| 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. | 86.929 | −0.017 |
Intercept 0.07 + feature contributions = 2.433 (log-odds).
Score = sigmoid(2.433) = 0.919.
| Score | 0.561 |
|---|
| Score | 38 |
|---|
Run 1
The code is highly readable. The structure is logical: imports are grouped by source and then classes/functions follow, with related methods cohesive within a mixin. Nesting is minimal, restricted to a single level in conditionals and a generator expression. Intent is clearly conveyed through descriptive names (register_hook, deregister_hook), type hints, and concise docstrings explaining behavior. Length is appropriate, importing only necessary utilities even if the import block is long—it is standard for library code. Each line performs one action. Reading flow is natural: imports, then class definition, with the deregister_hook's try/except clearly mapping to success/failure. Minor notes: the inline comment in the generator is helpful, and the isinstance check against Callable—though correct for runtime—can be slightly unusual since callable() exists, but not a readability flaw in this codebase.
Run 2
The code is well-structured with clear imports and logical class organization. Nesting is minimal, action granularity is good, and reading flow is natural. The hooks mixin methods are concise and focused. Minor deductions: the defensive runtime filter comment interrupts readability slightly, and some imports are unused or redundant (e.g., typing imports, 'hooks' type annotation could be clearer). The 'RequestHooksMixin' class lacks a clear docstring explaining its purpose, and the type annotation for 'hooks' dict could be more descriptive. Overall, very readable.
Run 3
The code is generally readable and follows common Python patterns. The imports are logically grouped and alphabetically sorted, which aids navigation. The RequestHooksMixin class has a clear purpose and the methods are concise with appropriate type hints and docstrings. However, readability is reduced by the large number of imports, which can overwhelm a reader at first glance. The register_hook method uses a generator expression with a defensive runtime filter, which is slightly dense but still understandable. The use of `hasattr(hook, "__iter__")` is acceptable but less explicit than `isinstance(hook, Iterable)`. The `deregister_hook` method is flat and straightforward. Overall, the code is maintainable but not exceptional in terms of reading flow, scoring 14 out of 20 due to the import volume and minor abstraction choices.
Run 1
Code Structure: Imports are grouped coherently, and hook registration and removal are separated into focused methods. Nesting: Shallow conditionals and a simple try/except keep complexity low. Clarity of intent: Descriptive names, type annotations, docstrings, and the defensive-filter comment clearly communicate behavior, although silently ignoring non-callable iterable items is slightly surprising. Code length: The methods are concise, but the extensive import section dominates this small excerpt and includes many imports not used here. Action granularity: Statements generally perform one action each; the generator expression remains straightforward. Reading flow: Registration proceeds naturally from event validation to adding hooks, and deregistration clearly handles success and failure. Import volume and minor formatting inconsistencies slightly interrupt an otherwise clean flow.
Run 2
Code Structure: Imports are grouped sensibly, and hook management is encapsulated in a focused mixin, although many imports are unused in this excerpt. Nesting: Methods remain shallow, with straightforward conditionals and a simple try/except. Clarity of intent: Descriptive method names, type annotations, docstrings, and a defensive-filter comment make behavior easy to understand; hasattr-based iterable checking is slightly less explicit. Code length: The methods are concise, but the extensive import section dominates this small excerpt. Action granularity: Statements generally perform one action per line, and the generator expression clearly handles filtering. Reading flow: Registration and deregistration appear in a natural order, with early validation and clear return paths; the lengthy imports delay reaching the relevant logic.
Run 3
Code Structure: Imports are grouped coherently, and hook management is encapsulated in a small mixin with focused methods, although the extensive imports distract from the short implementation. Nesting: Control flow is shallow, with simple conditionals and a straightforward try/except. Clarity of intent: Descriptive method names, type annotations, docstrings, and the defensive-filter comment explain behavior well; the iterable check and silent rejection of non-callable entries require some interpretation. Code length: Methods are concise, but the import-heavy excerpt adds substantial reading overhead. Action granularity: Each statement performs a distinct action, with no compressed multi-statement lines. Reading flow: Registration followed by deregistration is natural, and spacing is generally clear, though the wrapped generator expression and trailing comment slightly interrupt scanning.