Sample
pyint-00108635d51b-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.508 | 0–1; higher is more readable |
| LLOC | 36 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.67 | 0–20; mean of three runs |
| BTTF | 0.458 | 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. | 1916.47 | −63.244 |
| Source linesThe number of non-empty source lines. | 88 | +35.2 |
| 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.631 | −6.946 |
Intercept 8.87 + feature contributions = -26.12 (log-odds).
Score = sigmoid(-26.12) = 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. | 89 | −2.115 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 74 | +1.822 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 74 | −1.277 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 87.948 | +0.82 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 94.944 | +0.727 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.037 | +0.584 |
| 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.921 | −0.355 |
Intercept 0.07 + feature contributions = 0.277 (log-odds).
Score = sigmoid(0.277) = 0.569.
| Score | 0.508 |
|---|
| Score | 36 |
|---|
Run 1
The code is generally highly readable with clear imports, consistent type hints, and descriptive method documentation. Structure is logical, nesting is minimal, and intent is explicit. Minor issues include a redundant `socket` import and a meaningless `while` loop in `close()`, which slightly detracts from clarity. Overall, it's clean, well-organized, and easy to follow.
Run 2
The code is well-structured with clear imports and a simple class definition. It follows good practices like using type hints, docstrings, and future annotations. The nesting is minimal, and intent is clear for a base adapter class. However, the close() method contains a pointless while loop that serves no purpose, which hurts clarity and action granularity. Reading flow is natural due to logical grouping of imports, but the unused while loop and imported socket module with noqa comment suggest minor code cleanliness issues. Overall, the code is readable but has a few unnecessary elements that could be cleaned up.
Run 3
The code is well-structured with organized imports, clear type hints, and good docstrings. The BaseAdapter class has a clean, flat design. Intent is clear. However, there is a suspicious meaningless loop in close() that detracts from readability. Some import ordering could be slightly improved (nested imports before top-level). The send() method has a reasonable number of parameters with clear documentation. Overall the code is quite readable despite the odd loop in close() and minor import ordering issues.
Run 1
Code Structure: Imports and adapter methods are logically organized, but many imports are unused in this snippet, and referenced annotation names are not visibly defined. Nesting: Very shallow, with only one simple loop. Clarity of intent: The abstract adapter interface and send parameters are well documented; however, the countdown in close has no apparent purpose and conflicts with its cleanup description. Code length: The extensive imports and parameter documentation outweigh the minimal implementation, while the constructor and countdown add unnecessary code. Action granularity: Statements consistently perform one action per line. Reading flow: Conventional formatting and descriptive method names make the interface easy to follow, but import clutter and the unexplained loop interrupt an otherwise natural progression.
Run 2
Code Structure: Imports and the adapter interface are logically organized, but the large import block overwhelms the small class and includes many unused names. Nesting: Very shallow; only a simple loop introduces nesting. Clarity of intent: Descriptive method names, type annotations, and the send docstring clearly communicate the interface. However, PreparedRequest and _t are undefined in the snippet, and the pointless countdown in close obscures its purpose. Code length: The interface is concise, but unused imports, a trivial constructor, and the countdown add unnecessary length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The class progresses naturally from initialization to sending and cleanup, although excessive imports and inconsistent spacing between sections interrupt the flow.
Run 3
Code Structure: Imports and adapter methods are logically grouped, but many imports are unused in this snippet, creating clutter. Nesting: Mostly flat, with only a simple loop. Clarity of intent: The base adapter interface and send parameters are well documented, but PreparedRequest and _t are not defined or imported here, and the countdown in close has no apparent purpose. Code length: The extensive imports and parameter documentation outweigh the small implementation; the redundant initializer and countdown add unnecessary length. Action granularity: Statements generally perform one action per line. Reading flow: Conventional formatting and descriptive method names support natural reading, but import volume, unresolved annotation names, and the unexplained loop interrupt it.