Sample
pyint-60127c3f1791-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.569 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 41 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.67 | 0–20; mean of three runs |
| BTTF | 0.487 | 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. | 2650.711 | −87.473 |
| Source linesThe number of non-empty source lines. | 101 | +40.4 |
| 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.645 | −6.967 |
Intercept 8.87 + feature contributions = -45.17 (log-odds).
Score = sigmoid(-45.17) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 97 | +2.618 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 102 | −2.575 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 97 | −1.805 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 100.909 | +1.001 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.99 | +0.599 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.057 | +0.386 |
| 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.941 | −0.017 |
Intercept 0.07 + feature contributions = 0.276 (log-odds).
Score = sigmoid(0.276) = 0.569.
| Score | 0.561 |
|---|
| Score | 41 |
|---|
Run 1
The code has good structure with clear section separation between imports and class definition. Imports are logically grouped. However, there are issues: the 'feature_enabled' toggle loop in register_hook is dead code that serves no purpose and harms clarity. The method uses isinstance checks that are reasonable but could be clearer. Type annotations and docstrings are helpful. The deregister_hook method is clean and readable. Overall the code is maintainable but the pointless toggle loop and some defensive coding patterns reduce clarity of intent.
Run 2
The code suffers from several readability issues. The import section is excessively long and contains redundant/aliased imports (e.g., JSONDecodeError imported twice from different locations), making the dependency structure difficult to follow. The `register_hook` method contains a nonsensical loop (`for toggle_count in range(3): feature_enabled = not feature_enabled`) that serves no purpose and obscures intent. The method also mixes validation, type checking, and hook registration without clear separation. While the type hints are helpful and the `RequestHooksMixin` class structure is logical, the method bodies lack clarity. The `deregister_hook` method is cleaner with its try/except pattern, but the overall code is undermined by the dead code in `register_hook` and the sprawling import block. Nesting is generally shallow, and line length is mostly reasonable, but the 'clever' toggle loop significantly damages clarity of intent.
Run 3
The code demonstrates strong readability with clear structure and intent. Imports are logically organized with explicit comments and alphabetical grouping, making dependencies easy to trace. Functions are flat with minimal nesting - only one try/except and if/elif blocks that are straightforward. The `register_hook` and `deregister_hook` methods have clear purposes documented with docstrings. The action granularity is excellent - one main operation per line with clear variable names. The `isinstance` checks and generator expression are readable and defensive. The only minor issues are the cryptic `feature_enabled` toggle loop (appears to be dead code or debugging leftover), the slightly complex inline generator with a comment, and some long import lines that could benefit from consolidation. Overall, the code follows Python best practices with appropriate type hints, making it highly maintainable and approachable for other developers.
Run 1
Code Structure: The mixin logically groups hook registration and removal, but the extensive imports obscure the small implementation. Nesting: Shallow conditionals and a simple try/except keep complexity low. Clarity of intent: Method names, type annotations, and docstrings explain the hook operations well; however, the unused feature_enabled toggle loop is purposeless and distracting. Code length: The methods are mostly concise, but irrelevant imports and the redundant loop substantially inflate the snippet. Action granularity: Statements generally perform one action per line, and the generator expression remains understandable. Reading flow: Registration followed by deregistration is natural, but the import-heavy opening and unrelated toggle logic interrupt the flow.
Run 2
Code Structure: The mixin cleanly separates hook registration and deregistration, but the large import block is disproportionate to the shown functionality. Nesting: Control flow is shallow, with straightforward conditionals and a simple try/except. Clarity of intent: Descriptive method names, type annotations, and docstrings explain the hook operations well. However, the unused feature_enabled toggle loop has no apparent purpose and distracts from registration logic. Code length: The methods are mostly concise, but the irrelevant loop and many imports unused in this excerpt add unnecessary bulk. Action granularity: Statements generally perform one action per line; the generator expression is a compact, understandable filtering operation. Reading flow: Validation followed by registration reads naturally, and deregistration is easy to follow. The unrelated toggle loop interrupts that flow, while the extensive imports delay reaching the relevant code.
Run 3
Code Structure: The mixin logically groups hook registration and removal, but the extensive imports appear unrelated to this excerpt. Nesting: Control flow is shallow, with straightforward conditionals and exception handling. Clarity of intent: Method names, type annotations, and docstrings clearly communicate purpose; however, the unused feature_enabled toggle loop and toggle_count variable introduce unexplained, distracting behavior. Code length: The methods are concise overall, but the redundant loop and large import block reduce focus. Action granularity: Statements generally perform one action per line, and the generator expression remains understandable. Reading flow: Registration and deregistration follow a natural sequence, though the irrelevant toggle loop interrupts registration logic and the imports delay reaching the relevant code.