Sample
pyint-bf7e10b68ef6-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.192 | 0–1; higher is more readable |
| Mi | 0.425 | 0–1; higher is more readable |
| LLOC | 78 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.475 | 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. | 5435.556 | −179.373 |
| Source linesThe number of non-empty source lines. | 170 | +68 |
| 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.515 | −6.773 |
Intercept 8.87 + feature contributions = -109.276 (log-odds).
Score = sigmoid(-109.276) = 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. | 171 | −5.018 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 136 | +3.967 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 136 | −2.7 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 169.777 | +1.963 |
| 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. | 110.988 | −1.036 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 110.959 | +0.986 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.063 | +0.329 |
Intercept 0.07 + feature contributions = -1.439 (log-odds).
Score = sigmoid(-1.439) = 0.192.
| Score | 0.425 |
|---|
| Score | 78 |
|---|
Run 1
The code is well-structured and readable. It uses clear class naming, type hints, and docstrings. Methods are focused and maintain flat, logical flow within each function. The `open` method has a moderate level of branching but uses comments to clarify intent. Context managers and ExitStack are used appropriately to manage resources. Some complex logic around request building and state management slightly reduces clarity, but overall action granularity and reading flow are strong.
Run 2
The code is generally readable but has areas that could be improved. It has a clear class structure and docstrings, which help with intent. However, the `open` method contains a long if-elif-else block with multiple actions per line and nested type checks, reducing clarity. The `session_transaction` method mixes context management and session logic, which hurts the reading flow. Type hints are helpful, but some lines are dense and the action granularity is uneven. Variable names are descriptive, but overall flow could be more linear.
Run 3
The code is relatively readable but has moderate issues. Structure follows logical class methods and type hints improve clarity, but docstring length and some comments feel excessive. Nesting is acceptable, mostly within `open` and `session_transaction`, though the `if args and isinstance(...)` block in `open` creates multi-branch logic that is somewhat dense. Intent is generally clear due to naming and docstrings, but `_copy_environ` has a cryptic side effect (assigning a method to a debug environ key). Code length is reasonable but could be shorter; some comments repeat code logic. Action granularity is mostly one action per line, except in `_copy_environ` where dictionary merging and conditional assignment occur tightly. Reading flow is mostly linear but gets interrupted by the large `if/elif/else` in `open` and mixed responsibilities in methods like `session_transaction` (cookie checks, context handling, session save). Overall, the code is maintainable but not exemplary for readability.
Run 1
Code Structure: Methods logically separate session handling, environment preparation, request creation, and context management. Nesting: Mostly shallow, with modest nested branching in open(). Clarity of intent: Descriptive method names, type annotations, docstrings, and lifecycle comments explain the purpose well; abbreviated variables and externally defined types slightly reduce standalone clarity. Code length: Appropriately sized methods and reusable helpers keep implementation concise, although documentation is lengthy and some imports appear unused in this excerpt. Action granularity: Statements generally perform one action per line, with a few chained calls and a long assignment increasing reading effort. Reading flow: Initialization, helper methods, request execution, and context-manager methods follow a natural progression. Session and preserved-context lifecycles require careful attention, and the 'request is None' comment is misleading because it does not describe an actual check.
Run 2
Code Structure: Cohesive class with well-separated methods and helper functions, although some imports are unused and referenced types are not defined in the snippet. Nesting: Generally shallow, with moderate branching in open() to support multiple input types. Clarity of intent: Descriptive names, type annotations, docstrings, and context-management comments explain most behavior; abbreviated variables and the misleading 'request is None' comment slightly reduce clarity. Code length: Reasonably concise for the functionality, though documentation is lengthy and some request-building logic repeats. Action granularity: Statements generally perform one action per line, with a few dense chained calls and dictionary expressions. Reading flow: Methods follow a natural initialization, session handling, request construction, and context cleanup progression. Specialized context-preservation behavior requires careful reading, but overall organization remains easy to follow.
Run 3
Code Structure: Cohesive class with well-separated methods for sessions, request construction, and context management; some unused imports and externally defined types distract. Nesting: Generally shallow, with modest branching in open() and effective early exits. Clarity of intent: Descriptive method names, type annotations, docstrings, and lifecycle comments explain most behavior; abbreviated variables and subtle context preservation require framework knowledge. Code length: Mostly appropriate, though lengthy documentation and repeated request-type handling slightly increase reading effort. Action granularity: Statements generally perform one action per line, with a few chained calls and a long assignment reducing scanability. Reading flow: Methods follow a natural progression, and cleanup logic is clearly marked; limited spacing between import groups and the class, plus the misleading 'request is None' comment, slightly weaken readability.