Sample
pyint-b95f3c241e8c-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.872 | 0–1; higher is more readable |
| Mi | 0.508 | 0–1; higher is more readable |
| LLOC | 33 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.33 | 0–20; mean of three runs |
| BTTF | 0.729 | 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. | 1816.539 | −59.946 |
| Source linesThe number of non-empty source lines. | 85 | +34 |
| 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 = -24.039 (log-odds).
Score = sigmoid(-24.039) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 86 | −2.009 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 71 | +1.719 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 84.938 | +0.777 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 94.965 | +0.728 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.036 | +0.59 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 94.977 | −0.358 |
Intercept 0.07 + feature contributions = 1.916 (log-odds).
Score = sigmoid(1.916) = 0.872.
| Score | 0.508 |
|---|
| Score | 33 |
|---|
Run 1
The code demonstrates good organization with logical import grouping (stdlib, third-party, local) and clear separation of concerns. The BaseAdapter class has a single responsibility with well-documented abstract methods. Nesting is minimal and the code flows naturally. Type hints improve readability and intent. The docstrings are comprehensive, explaining parameters clearly. Import section is lengthy but necessary for the adapter's functionality. Minor deductions: some unused imports (socket with noqa, typing) create slight noise, and the imports could potentially be condensed. The class structure is clean with no unnecessary complexity or deep nesting. Action granularity is appropriate - each method has a single clear purpose. The code achieves good balance between being concise and explicit. Overall, this is highly maintainable code that would be easily understood by other developers.
Run 2
The code demonstrates generally good readability with clear structure and organization. Imports are logically grouped by source (standard library, third-party, local modules), and the class has a single clear purpose as a base adapter. The send method has a well-documented signature with type hints and descriptive parameter documentation. Nesting is minimal, code length is appropriate for the functionality shown, and each line generally represents one logical action. The reading flow is natural, moving from imports to class definition to methods. However, there are minor readability concerns: the unused socket import with noqa comment is slightly confusing, the wildcard-style grouped imports make some dependencies unclear, and the NotImplementedError pattern in both methods could be improved with an abstract class approach or more explicit documentation of the contract. Overall, the code is quite readable and maintainable.
Run 3
The code is well-structured and readable, with clear separation of imports, class definition, and method signatures. Type hints and docstrings improve clarity of intent. The import block is long but logically grouped. Nesting is minimal and the class is short, avoiding unnecessary complexity. The 'send' method has many parameters but is appropriately documented. One minor issue is the unused `socket` import with a noqa comment, which slightly detracts from cleanliness. Overall, the code follows best practices and is maintainable.
Run 1
Code Structure: Imports are grouped by source, followed by a small, logically organized adapter interface, though many imports are unrelated to the shown class. Nesting: Methods are flat and easy to scan. Clarity of intent: Descriptive method names, type annotations, and detailed docstrings clearly communicate the interface; however, PreparedRequest and _t are not defined or imported in the snippet, making annotation references harder to follow. Code length: The class is concise, but the large import section, trivial constructor, and lengthy parameter documentation add overhead relative to the implementation. Action granularity: Statements generally perform one action per line, and the multiline signature is readable. Reading flow: The progression from imports to initialization, sending, and cleanup is natural, although import clutter and limited separation between import groups slightly weaken it.
Run 2
Code Structure: Imports are grouped and the adapter interface is logically organized, although many imports are unused in this excerpt and annotation names PreparedRequest and _t lack visible definitions. Nesting: There is no unnecessary nesting; methods are flat and easy to inspect. Clarity of intent: Descriptive method names, type annotations, docstrings, and NotImplementedError clearly communicate an abstract transport interface. Code length: The large import block and extensive send documentation outweigh the minimal implementation, and the constructor adds little value. Action granularity: Each statement performs one action, and multiline signatures and imports remain readable. Reading flow: The progression from dependencies to class initialization, sending, and cleanup is natural, but import clutter and unresolved annotation references interrupt comprehension.
Run 3
Code Structure: Imports and a small adapter interface are logically organized, though many imports are unused in this excerpt. Nesting: Methods are flat, with no complex control flow. Clarity of intent: Descriptive method names, type annotations, and parameter documentation clearly communicate the interface; however, PreparedRequest and _t are not defined or imported in the shown code, making annotations harder to interpret. Code length: The implementation is concise, but the extensive import block, verbose docstring, and trivial constructor add overhead relative to the functionality shown. Action granularity: Each statement performs a single action, and multiline signatures improve scanning. Reading flow: The progression from imports to class and methods is natural, although the disproportionate import section and limited spacing between top-level sections slightly reduce readability.