Sample
pyint-22237fa598b7-I11
Split eligible integer literals into pairs of short-named intermediate variables
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 | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.67 | 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 is generally well-structured and readable. Imports are logically grouped and alphabetized. Classes and methods have clear names and docstrings that explain intent. Nesting is minimal; the code is flat. Each line typically performs one action. The main weaknesses are the long import list, which increases visual noise, and the unused 'socket' import marked with noqa, which suggests legacy clutter. Type hints improve clarity but add length. Overall, the code is concise, organized, and easy to follow, with only minor readability drawbacks.
Run 3
The code is generally well-structured with clear imports, logical grouping of exceptions, and sensible class organization. It avoids deep nesting and maintains a flat structure. The intent is clear: it defines an abstract BaseAdapter with NotImplementedError methods. However, the code is somewhat verbose due to extensive imports and docstring parameters that repeat type information, which reduces readability. The action granularity is good—one action per line—and reading flow is natural with consistent formatting. Some unused imports (socket, typing) and redundant type hints in docstrings could be trimmed to improve conciseness and clarity.
Run 1
Code Structure: Imports and a small adapter interface are logically organized, although the extensive import block overwhelms the implementation. Nesting: Flat methods with no nested control flow make scanning easy. Clarity of intent: Descriptive method names, type hints, and detailed docstrings clearly communicate the adapter contract; 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 many imports are unused in this excerpt, and the trivial constructor adds little value. Action granularity: Each statement performs one action, with multiline signatures and imports formatted clearly. Reading flow: The class progresses naturally from initialization to sending and cleanup, though inconsistent import grouping and the lengthy preamble slightly disrupt the flow.
Run 2
Code Structure: Imports are grouped and the adapter interface is logically organized, though many imports are unused in this snippet. Nesting: Flat methods and no nested control flow make scanning easy. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly communicate the transport adapter contract; however, PreparedRequest and _t are not defined or imported in the shown code. 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: Each statement performs one action, with signatures and imports cleanly split across lines. Reading flow: The progression from dependencies to class initialization, sending, and cleanup is natural, although the lengthy import section delays reaching the interface.
Run 3
Code Structure: Imports are grouped and the adapter interface is logically organized, but many imports are unused in this excerpt, and PreparedRequest and _t lack visible definitions. Nesting: Very shallow, making methods easy to scan. Clarity of intent: Descriptive method names, annotations, and docstrings clearly communicate the transport adapter contract, although unresolved annotation names reduce self-containment. Code length: The implementation is concise, but the extensive import list and detailed send docstring dominate a small interface; the constructor adds little value. Action granularity: Each statement performs one action, and parameters and imports are formatted cleanly on separate lines. Reading flow: The progression from imports to class initialization, sending, and cleanup is natural, though import clutter and limited spacing between major sections slightly hinder scanning.