Sample
pyint-d802e4513ae9-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.001 | 0–1; higher is more readable |
| Mi | 0.617 | 0–1; higher is more readable |
| LLOC | 180 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs |
| BTTF | 0.423 | 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. | 15583.684 | −514.262 |
| Source linesThe number of non-empty source lines. | 559 | +223.6 |
| 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.534 | −6.802 |
Intercept 8.87 + feature contributions = -288.593 (log-odds).
Score = sigmoid(-288.593) = 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. | 560 | −18.792 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 366 | +11.922 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 366 | −7.978 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 558.925 | +7.403 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 105.984 | +0.906 |
| 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. | 105.945 | −0.822 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.048 | +0.479 |
Intercept 0.07 + feature contributions = -6.811 (log-odds).
Score = sigmoid(-6.811) = 0.001.
| Score | 0.617 |
|---|
| Score | 180 |
|---|
Run 1
The code demonstrates generally strong readability through clear class and method organization, consistent type hints, and informative docstrings that explain intent. Structure is logical, grouping request preparation, HTTP methods, sending, and environment settings. Nesting is mostly shallow, with clean if-blocks and no deeply nested logic. Intents are clear: each method has a single focused purpose and helper methods isolate concerns such as adapter selection and environment merging. Length is moderate—docstrings and verbose comments add lines, but they materially improve clarity for a public-facing API. Action granularity is good, with generally one meaningful operation per line, though a few dictionary updates and conditional assignments could be split for maximum clarity. Reading flow is natural: the class progresses from initialization to request preparation, sending, and helper utilities. Deductions come from lengthy parameter lists and some dense type annotations that can visually overwhelm, but overall this is a well-structured, maintainable code sample.
Run 2
The code is highly readable. Structure is logical, with clear class organization and methods that follow a natural request lifecycle. Nesting is shallow; the most complex logic in `send` and `merge_environment_settings` remains only two levels deep. Intent is explicit through descriptive names, type hints, docstrings, and documentation of important defaults like `verify`. Despite being long, the length is justified by thorough documentation and optional parameters. Each line generally performs one action. Reading flow is natural: methods such as `prepare_request`, `request`, and HTTP verb shortcuts progress in a coherent order. Minor deductions: some long signatures and dense docstrings slightly slow scanning, and a few sections (e.g., cookie merging) could use a brief inline explanation. Overall, very clear maintenance-oriented code.
Run 3
The code demonstrates strong readability through clear structure and organization. The Session class is logically divided into well-defined methods with consistent naming and clear purposes. Imports are properly organized with future annotations. Type hints are extensively used, improving clarity. The code maintains a flat nesting structure with minimal indentation levels. Each method has a focused responsibility, following single-action-per-line patterns. Documentation strings are thorough, providing examples and parameter descriptions. The HTML-like comments for section separation (e.g., 'Bootstrap CookieJar', 'Send the request') improve reading flow. While the code is relatively long, this is justified by the complexity and comprehensive documentation required for a Session class handling HTTP requests. Minor deductions: the 'send' method has slightly more complex logic with cookie handling and redirect resolution, and some methods like 'mount' could benefit from additional inline comments explaining the adapter sorting logic. Overall, this is exemplary code that balances completeness with readability.
Run 1
Code Structure: Methods logically separate initialization, request preparation, sending, configuration merging, and adapter management. Nesting: Mostly shallow, with modest additional nesting in environment and redirect handling. Clarity of intent: Descriptive method names, type annotations, and documentation explain the API well; abbreviated variables such as p, r, k, and v and references undefined in this excerpt reduce clarity. Code length: Implementation is generally concise, but extensive repetitive docstrings and comments increase scanning effort; send handles several responsibilities. Action granularity: Statements generally perform one action each, and multiline calls clearly separate arguments, though nested cookie merging compresses multiple steps. Reading flow: Request creation, preparation, sending, and response processing follow a natural progression with helpful whitespace. Missing helper definitions and imports require external context, and the bare r.content expression obscures its side effect.
Run 2
Code Structure: Methods logically separate configuration, request preparation, sending, and adapter management; HTTP convenience methods consistently delegate. Nesting: Mostly shallow, with modest additional nesting in environment merging and redirect handling. Clarity of intent: Descriptive method names, annotations, and documentation explain behavior well, although short variables such as p and r and externally undefined helpers/types reduce standalone clarity. Code length: Executable logic is reasonably concise, but extensive, repetitive documentation and a long request signature increase scanning effort. Action granularity: Statements generally perform one action each; nested cookie merging and implicit content loading through r.content are less immediately transparent. Reading flow: The lifecycle proceeds naturally from initialization through preparation and transmission to cleanup. Consistent formatting and comments aid navigation, though send combines several responsibilities and numerous imports add visual overhead.
Run 3
Code Structure: Methods logically separate initialization, request preparation, sending, configuration, and adapter management, although send handles several responsibilities. Nesting: Mostly shallow, with moderate nesting in environment merging and redirect handling. Clarity of intent: Descriptive method names, annotations, and documentation explain the API well; abbreviated variables such as p, r, and v and dependencies not defined or imported in the snippet reduce clarity. Code length: Executable logic is generally concise, but extensive repeated documentation and HTTP-method wrappers make the class lengthy. Action granularity: Statements generally perform one action, and multiline calls are well formatted; nested cookie merging and implicit content loading through r.content require extra interpretation. Reading flow: The progression from setup through preparation, execution, and cleanup is natural, with helpful whitespace and comments. Long signatures, verbose documentation, and missing helper definitions occasionally interrupt that flow.