Sample
pyint-bb7b21d0098b-SRC
Unmodified source class
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 | 15.33 | 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 generally readable with clear imports and a logical class structure. The RequestHooksMixin has a single responsibility and uses type hints well. However, the large import block is verbose and could be considered unnecessarily long, though this is common in compatibility-focused libraries. The register_hook method has moderate nesting with an if-elif structure and a defensive generator filter that is somewhat dense. The isinstance check for Callable works but is not ideal for checking callables in all Python versions. The deregister_hook's try-except for flow control is acceptable but slightly less clear than using a conditional. Line-level granularity is mostly good, with one action per line in most cases. The reading flow is natural and the intent is clear from method names and docstrings.
Run 2
The code is well-structured and readable. Imports are logically grouped by source (stdlib, third-party, local) with multiple related names per line, which is concise but slightly dense. The class and methods are clear with type hints and docstrings explaining intent. Nesting is minimal: a single conditional in register_hook with flat branches. Action granularity is appropriate—most lines perform one logical operation, though the generator expression in extend() combines iteration and filtering on one line. Reading flow is natural: validation before mutation, clear error handling in deregister_hook with an explicit try/except that avoids deeper nesting. Minor deductions for the dense import blocks and a few lines that could be split for clarity, but overall the code is maintainable and easy to follow.
Run 3
The code is generally readable with clear structure and intent. Imports are organized and type hints improve clarity. However, the massive import block at the top is lengthy and somewhat overwhelming, reducing initial readability. The RequestHooksMixin class has clear methods with docstrings, good action granularity, and minimal nesting. The 'isinstance(hook, Callable)' check works but is semantically unusual since Callable is used as a type, not a class for isinstance checks (though it functions). The 'defensive runtime filter' comment adds helpful context but the generator expression could be slightly more explicit for clarity. Overall, the code is maintainable and logically organized, but the verbose import section and minor implementation quirks prevent it from scoring higher.
Run 1
Code Structure: Imports are grouped by source, and hook management is cleanly encapsulated in a mixin with two focused methods. Nesting: Shallow conditionals and a simple try/except keep complexity low. Clarity of intent: Descriptive method names, type annotations, and docstrings make registration and deregistration clear, though silently filtering non-callable iterable elements is somewhat implicit. Code length: Methods are concise, but the extensive imports, mostly unused in this excerpt, distract from the small implementation. Action granularity: Statements generally perform one action each; the generator expression remains straightforward. Reading flow: Validation precedes registration naturally, and deregistration follows a clear success/failure path. The long import preamble and slightly awkward wrapping of the extend call modestly reduce readability.
Run 2
Code Structure: Imports are grouped logically, and hook operations are cleanly encapsulated in a focused mixin, though the large import section overwhelms the small implementation. Nesting: Methods remain shallow, with straightforward conditionals and exception handling. Clarity of intent: Descriptive method names, type annotations, docstrings, and explicit error messages make behavior clear; the defensive iterable filter adds slight complexity. Code length: Methods are concise, but many imports are unused in the provided excerpt, increasing reading overhead. Action granularity: Statements generally perform one action each; the generator expression combines filtering and iteration compactly without becoming obscure. Reading flow: Registration followed by deregistration is natural, and early validation improves flow. Extra spacing before the class and a more explanatory registration docstring would improve presentation.
Run 3
Code Structure: Imports are grouped coherently, and the mixin separates registration and deregistration into focused methods. Nesting: Control flow is shallow, with straightforward conditionals and a small try/except block. Clarity of intent: Descriptive method names, type annotations, and docstrings make hook management clear; the defensive filter explains why non-callable iterable elements are ignored. Code length: Methods are concise, but the extensive import section is disproportionate to this excerpt and includes many names not used here. Action granularity: Each statement generally performs one action, while the generator expression compactly expresses filtering. Reading flow: Validation precedes mutation naturally, and deregistration follows a simple success/failure pattern. Minor drawbacks include the abbreviated '_t' alias, a generic registration docstring that omits filtering behavior, and substantial import overhead before the relevant logic.