Sample
pyint-db004d5daaa3-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.921 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.574 | 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. | 2575.178 | −84.981 |
| Source linesThe number of non-empty source lines. | 100 | +40 |
| 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.642 | −6.963 |
Intercept 8.87 + feature contributions = -43.074 (log-odds).
Score = sigmoid(-43.074) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 96 | +2.583 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 101 | −2.54 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 99.898 | +0.987 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.98 | +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.375 |
| 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.96 | −0.018 |
Intercept 0.07 + feature contributions = 2.454 (log-odds).
Score = sigmoid(2.454) = 0.921.
| Score | 0.561 |
|---|
| Score | 39 |
|---|
Run 1
The code has serious readability problems. The import section is excessively long (over 40 lines) with multiple aliases and 'noqa' comments, suggesting scope creep or copied boilerplate rather than minimal dependencies. The `register_hook` method contains a confusing double-negative condition: 'if not (event not in self.hooks)' with an empty 'pass' branch followed by 'else: raise ValueError'. This inverted logic makes intent difficult to parse - it would be clearer as 'if event not in self.hooks: raise ValueError(...)'. The hook registration also has unclear action granularity: the generator expression with inline comment is packed into a single statement. The class has an undefined type annotation `_t.HookType` which adds ambiguity. While the code uses type hints and docstrings, the tangled conditionals and heavy import section make it difficult to follow. The file appears to lack modular separation of concerns, loading many unrelated utilities. The overall structure feels like a monolithic utility module rather than focused, readable code.
Run 2
The code has clear structure with organized imports and well-defined class methods, but contains several readability issues. The condition in register_hook uses an awkward double negative logic ('if not (event not in self.hooks)') with empty pass/else branches, making the intent unclear and the flow unnatural. The defensive filter in the extend call uses a generator expression that, while functional, could be clearer with a list comprehension or separate loop. Import organization is logical but verbose, with multiple aliased imports that add cognitive overhead. The mixin pattern is clear, and method purposes are documented, but the hook validation logic undermines clarity. Overall the code is maintainable but would benefit from simplifying the conditional logic and removing unnecessary defensive complexity.
Run 3
The code is generally readable but has some structural issues. Imports are well-organized, and class methods have clear purposes with docstrings. The register_hook method has awkward inverted logic (`if not (event not in self.hooks): pass else: raise`) which reduces clarity of intent. Action granularity is mostly good with one action per line, but the generator expression with inline comment could be clearer. Nesting is appropriately flat. The deregister_hook method is concise with clear exception handling. Overall, the code is maintainable but the register_hook logic and some verbose import sections slightly reduce readability.
Run 1
Code Structure: Imports are grouped and hook operations are logically separated into two methods, though the large import block overwhelms the small class. Nesting: Mostly shallow, but register_hook introduces an unnecessary if/pass/else branch. Clarity of intent: Method names, type annotations, and docstrings clarify purpose; the double-negative condition 'if not (event not in self.hooks)' obscures a simple membership check. Code length: Methods are concise, but many imports are unused in this snippet, and the validation branch could be shortened. Action granularity: Statements generally perform one action per line; the generator expression compactly combines filtering and iteration without becoming difficult to follow. Reading flow: Registration and deregistration follow a natural order, but the lengthy imports and awkward validation interrupt otherwise straightforward logic.
Run 2
Code Structure: Imports are grouped logically, and hook operations are separated into focused methods, although many imports are unused in this excerpt. Nesting: Generally shallow, but the unnecessary if/pass/else adds avoidable branching. Clarity of intent: Descriptive method names, type annotations, and docstrings make the purpose clear; the double-negative condition obscures a simple unsupported-event check. Code length: Methods are concise, but the extensive import block dominates this small excerpt. Action granularity: Statements generally perform one action per line, and the generator expression clearly filters callable hooks. Reading flow: Registration followed by deregistration is natural, but the awkward validation condition interrupts the flow. Overall, readable and well organized, with a conspicuous clarity issue in event validation.
Run 3
Code Structure: Imports are grouped and hook operations are organized into a focused mixin, though most imports are unused in this excerpt. Nesting: Methods are shallow, with straightforward conditional and exception handling. Clarity of intent: Descriptive method names, type annotations, and docstrings explain the purpose, but the double-negative condition `if not (event not in self.hooks)` and empty `pass` branch unnecessarily obscure validation. Code length: The methods are concise, but the extensive import section overwhelms the small amount of functional code shown. Action granularity: Statements generally perform one action per line; the generator expression compactly combines filtering and iteration without becoming difficult to follow. Reading flow: Registration and deregistration follow a natural sequence, but the inverted validation branch interrupts that flow. A direct `if event not in self.hooks: raise ValueError(...)` would improve readability.