Sample
pyint-df450b3790af-I11
Split eligible integer literals into pairs of short-named intermediate 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 | 17 | 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 demonstrates strong readability through clear class structure, logical import organization, and well-named methods. The RequestHooksMixin class has focused responsibilities with intuitive method names like register_hook and deregister_hook. Nesting is minimal with early validation handling edge cases. Type hints improve clarity and intent. Action granularity is appropriate - each line performs a distinct operation. The import block is verbose but organized by logical groups (stdlib, third-party, internal). However, some imports appear unused or redundant (encodings.idna, multiple SSLError imports with aliases), which slightly reduces clarity. The isinstance check with Callable is slightly unusual and could benefit from explanation. The defensive filter comment helps but the logic could be clearer. Overall flow is natural and readable.
Run 3
The code demonstrates good readability overall. The structure is logical with clear import organization and well-separated class definition. The RequestHooksMixin class has a clear, focused purpose with methods that are concise and follow the single responsibility principle. Nesting is minimal - the deepest nesting is a simple if/elif in register_hook and a try/except in deregister_hook. Intent is clear from naming and docstrings. Code length is appropriate - no unnecessary verbosity. Action granularity is well-maintained with one action per line. The reading flow is natural, moving from type hints to logic to return statements. Minor improvements could include adding type hints to deregister_hook's return annotation and slightly more detailed docstrings, but overall this is highly readable code.
Run 1
Code Structure: Imports are grouped by source, and hook operations are cleanly encapsulated in a mixin with separate methods. Nesting: Control flow is shallow, using straightforward conditionals and a small try/except. Clarity of intent: Descriptive method names, type annotations, docstrings, and an explanatory comment make registration and deregistration easy to understand, though silently filtering non-callables is slightly less obvious. Code length: Methods are concise, but the extensive import section adds substantial overhead to this short excerpt, with many imports unused here. Action granularity: Statements generally perform one action per line; the generator expression remains compact and readable. Reading flow: Validation precedes registration naturally, and deregistration follows a clear success/failure pattern. Minor spacing inconsistencies and the long import preamble slightly interrupt an otherwise clean flow.
Run 2
Code Structure: Imports are grouped clearly, and hook management is organized into a focused mixin, though many imports are unused in the shown excerpt. Nesting: Both methods use shallow conditionals or a simple try/except, making control flow easy to follow. Clarity of intent: Descriptive method names, type annotations, docstrings, and explicit error messages explain the purpose well; the runtime filtering behavior is less obvious from the brief register_hook docstring. Code length: The methods are concise, but the extensive import section outweighs the implementation shown. Action granularity: Statements generally perform one action each; the generator expression combines filtering and iteration compactly without becoming difficult to read. Reading flow: Registration and deregistration appear in a natural sequence, with validation before mutation and straightforward success/failure handling. Minor formatting issues, such as limited separation before the class and the split generator expression with a trailing comment, slightly reduce polish.
Run 3
Code Structure: Imports are grouped and hook operations are logically encapsulated in a mixin, though the extensive import block dominates this small excerpt. Nesting: Shallow conditionals and a straightforward try/except keep complexity low. Clarity of intent: Descriptive method names, type annotations, docstrings, and explicit errors make registration and deregistration easy to understand. Code length: Methods are concise, but many imports are unused in the shown excerpt and add visual overhead. Action granularity: Each statement performs one clear operation; the generator expression combines filtering and iteration compactly without becoming confusing. Reading flow: Validation precedes registration naturally, and deregistration follows a simple success/failure path. Minor distractions include the broad import list, the terse generator variable, and inconsistent spacing between the imports and class definition.