Sample
pyint-cc94dfe3b57f-I05
Rewrite eligible decimal integer literals in hexadecimal notation
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.67 | 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 strong readability through logical import grouping (standard library, third-party, local modules), consistent formatting, and clear type hints. The BaseAdapter class has a clear purpose with well-documented method signatures. Each import is on its own line and grouped logically. The class structure is flat with minimal nesting. Docstrings accurately describe parameters and return values. Minor deductions: the unused socket import with noqa comment indicates potential cleanup needed, and some type annotations use Any instead of more specific types. The send method signature is well-annotated but could benefit from a return type alias. Overall, the code follows Python best practices with excellent structure, clear intent, and maintainable organization.
Run 3
The code demonstrates strong readability. Imports are logically grouped (standard library, third-party, local) with explicit exception imports. The class has clear method separation with well-documented docstrings. Parameters use type hints and descriptive names. Nesting is minimal—the base class methods simply raise NotImplementedError, which is appropriate for abstract behavior. Each action is on its own line. Docstrings follow consistent formatting and explain parameters clearly. Minor deductions: the import block is extensive (though necessary), 'socket' is imported but marked noqa without explanation, and some type aliases rely on external definitions. Overall, the code is clean, maintainable, and easy to understand, following Python best practices and common package conventions.
Run 1
1. Code Structure: Imports are grouped, and the adapter interface is logically organized into initialization, sending, and cleanup. However, many imports are unused in this excerpt. 2. Nesting: Very flat, with no nested control flow. 3. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly communicate the interface. References to PreparedRequest and _t without visible definitions or imports reduce self-contained clarity. 4. Code length: Method bodies are concise, but the extensive import list and parameter documentation dominate this small interface; the constructor adds little. 5. Action granularity: Each statement performs a single action, and multiline signatures are easy to scan. 6. Reading flow: The progression from imports to the base class and its methods is natural, though the long import section delays reaching the core functionality.
Run 2
Code Structure: Imports are grouped and the adapter interface is logically organized, though many imports are unused in this excerpt. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly communicate the interface; however, PreparedRequest and _t are not defined or imported in the supplied code, making annotations harder to interpret. Code length: The implementation is concise, but the extensive import section and parameter documentation outweigh the small interface. Action granularity: Each statement performs one action, and multiline signatures remain readable. Reading flow: The progression from imports to class initialization, sending, and cleanup is natural, although import clutter delays reaching the core functionality.
Run 3
Code Structure: Imports are grouped and the adapter interface is logically organized, although 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 docstrings clearly communicate the interface; however, PreparedRequest and _t are not defined or imported in the shown code, making some annotations harder to interpret. Code length: The implementation is concise, but the extensive imports and parameter documentation outweigh the minimal behavior, and the constructor adds little value. Action granularity: Statements generally perform one action per line, while multiline signatures improve scanning. Reading flow: The progression from imports to initialization, sending, and cleanup is natural, though import clutter and inconsistent spacing between import groups slightly interrupt it.