Sample
pyint-a4e668f13f61-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.009 | 0–1; higher is more readable |
| Mi | 0.504 | 0–1; higher is more readable |
| LLOC | 198 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.399 | 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. | 16246.769 | −536.143 |
| Source linesThe number of non-empty source lines. | 455 | +182 |
| 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.301 | −6.451 |
Intercept 8.87 + feature contributions = -351.724 (log-odds).
Score = sigmoid(-351.724) = 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. | 456 | −15.109 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 455 | +15.001 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 455 | −10.02 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 454.91 | +5.949 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.071 | +0.253 |
| 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. | 87.923 | −0.059 |
Intercept 0.07 + feature contributions = -4.72 (log-odds).
Score = sigmoid(-4.72) = 0.009.
| Score | 0.504 |
|---|
| Score | 198 |
|---|
Run 1
The code shows generally good structure with clear class organization, type hints, and logical method separation. However, readability is reduced by several factors: heavy import blocks with many aliases, long methods like `cert_verify` and `send` that handle multiple concerns, deep nesting in error handling chains, and some inconsistent formatting (extra whitespace, mixed comment styles). The `send` method particularly suffers from try-except blocks spanning many lines with nested conditionals. While method names are explicit and intent is usually clear, the density of proxy/TLS/retry logic creates cognitive load. Action granularity is mostly one-action-per-line, but error handling cascades could be flattened or extracted. Reading flow is acceptable but punctuation-heavy sections and vertical sprawl reduce scannability. Overall it's professional-quality code that could benefit from refactoring the most complex methods.
Run 2
The code demonstrates good readability through clear method naming, consistent type hints, and logical organization. Structure is well-maintained with focused methods handling specific concerns (proxy managers, TLS verification, connection pooling). Nesting is generally shallow, though the send() method has multiple exception handling branches that slightly increase complexity. Intent is mostly clear - method names and docstrings (though sparse) convey purpose effectively. Code length is reasonable for the functionality but some methods like cert_verify() and send() are longer than ideal. Action granularity is good - most operations are one per line, though some exception blocks could be extracted. Reading flow is natural with logical progression from connection setup to response building. Minor deductions: some methods lack docstrings, exception handling in send() is verbose, and a few lines exceed recommended length. Overall, well-structured code with only minor readability concerns.
Run 3
The code is generally well-structured with clear method separation and type hints. However, there are several readability issues: unused imports (socket, typing), some methods with deeply nested conditionals (cert_verify has 4 levels), and long methods like send() that handle multiple concerns. The exception handling in send() creates complex nesting with multiple isinstance checks. Some comments are helpful but others are placeholders. The code follows consistent naming conventions and each logical action is mostly on its own line. The flow is natural for those familiar with HTTP adapters but may be confusing for newcomers due to the domain complexity. Overall readable but could benefit from refactoring long methods and reducing nesting depth.
Run 1
Code Structure: Responsibilities are logically separated into focused methods for pooling, proxies, TLS, response construction, and sending. Nesting: Mostly shallow, but certificate validation and exception translation introduce moderately nested branches. Clarity of intent: Descriptive method names and type hints help, while absent docstrings and undefined external names in the snippet obscure some contracts and dependencies. Code length: Much of the length reflects necessary functionality, though duplicated proxy setup and the lengthy send method could be simplified. Action granularity: Most lines perform a single action; chained assignments in proxy_manager_for are minor exceptions. Reading flow: Request preparation, execution, and response construction follow a natural sequence, but excessive blank lines, inconsistent whitespace, and extensive exception handling interrupt scanning.
Run 2
Code Structure: Responsibilities are logically divided into methods for pooling, proxies, TLS, response construction, and sending. Nesting: Mostly shallow, although certificate validation and exception translation introduce moderately nested branches. Clarity of intent: Descriptive method names and type annotations help, but missing docstrings and unexplained external names such as _t and _PoolManager reduce standalone clarity. Code length: Most methods are reasonably concise; send is lengthy, and the two connection methods duplicate proxy setup logic. Action granularity: Statements generally perform one action per line, with chained manager assignments as minor exceptions. Reading flow: Request preparation, execution, and response construction follow a natural sequence, but excessive blank lines, whitespace artifacts, and extensive exception handling interrupt the flow.
Run 3
Code Structure: Well-separated methods organize pooling, TLS verification, proxy handling, response construction, and sending, though send combines several responsibilities. Nesting: Mostly shallow, with moderate nesting in certificate validation and exception translation. Clarity of intent: Descriptive method names and type annotations help, but absent docstrings and several externally undefined names obscure context and extension hooks. Code length: Generally justified by functionality, although duplicated proxy setup and verbose exception handling add length. Action granularity: Most lines perform one action; chained manager/cache assignments are minor exceptions. Reading flow: Request preparation, execution, and response construction follow a natural sequence, but excessive blank whitespace, lengthy imports, and numerous exception branches interrupt scanning.