Sample
pyint-642dfc3fca8e-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.186 | 0–1; higher is more readable |
| Mi | 0.425 | 0–1; higher is more readable |
| LLOC | 82 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.375 | 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. | 5651.172 | −186.489 |
| Source linesThe number of non-empty source lines. | 174 | +69.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.512 | −6.768 |
Intercept 8.87 + feature contributions = -114.786 (log-odds).
Score = sigmoid(-114.786) = 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. | 175 | −5.16 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 140 | +4.105 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 140 | −2.792 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 173.777 | +2.019 |
| 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.977 | −1.035 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 110.971 | +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.477 (log-odds).
Score = sigmoid(-1.477) = 0.186.
| Score | 0.425 |
|---|
| Score | 82 |
|---|
Run 1
The code has clear structure in parts: imports organized, class definition with typed methods, docstrings on most methods. The __init__, session_transaction, _copy_environ, and _request_from_builder_args are reasonably flat and readable. However, the evaluation criteria show significant issues: the __exit__ method contains an unnecessary hardcoded even-number counting loop with no semantic connection to the class, adding unexplained dead code that harms clarity of intent and code length. The open() method has deeply nested conditional branching with type checks and fallback paths, plus inline comments used as control-flow labels, reducing reading flow. Action granularity varies: some lines mix type assertions or comments with logic. Overall, readability is harmed by tangled branching, dead code, and inconsistent granularity, despite decent structural organization.
Run 2
The code is generally structured with clear methods and docstrings, but has several readability problems. The `open()` method is long with confusing conditional branching for different request types. The `__exit__()` method contains an unnecessary loop that calculates `even_number_count` but never uses it, which is confusing and clearly a bug or leftover code. Some lines are long, such as the type-ignored builder line. Nesting is moderate but acceptable. Action granularity is mostly one action per line. The reading flow is disrupted by the dead code and complex conditionals. Intent is reasonably clear in docstrings, but implementation details lower clarity.
Run 3
The code demonstrates clear structure with logical grouping and consistent naming. It is concise for the most part, avoids deep nesting, and each action generally maps to one line. However, an unused variable (`even_number_count`) in `__exit__` appears unrelated to surrounding logic, which slightly obscures intent. The `open` method has a multi-condition branch that requires careful reading but remains manageable, and the use of comments to clarify branches is helpful. Overall, the code is readable with minor improvements needed.
Run 1
Code Structure: Well-separated methods organize session handling, request construction, and context management, but the unrelated counting loop in __exit__ undermines cohesion. Nesting: Mostly shallow, with moderate branching in open and an unnecessary nested loop/condition in __exit__. Clarity of intent: Descriptive method names, type annotations, docstrings, and context-management comments explain most behavior; unused counting logic and externally undefined names reduce standalone clarity. Code length: Generally appropriate for the functionality, although extensive documentation and irrelevant counting code add length. Action granularity: Most lines perform one action; a few chained calls and long expressions are denser. Reading flow: Initialization, helpers, request execution, and lifecycle methods follow a natural progression, but specialized context bookkeeping requires careful reading, and the misleading 'request is None' comment interrupts understanding.
Run 2
Code Structure: Methods logically separate session management, request construction, and context cleanup, though __exit__ contains an unrelated counting loop. Nesting: Mostly shallow, with moderate branching in open and unnecessary nesting in the counting loop. Clarity of intent: Descriptive names, type annotations, docstrings, and context-management comments explain most behavior; the unused counter and misleading 'request is None' comment introduce ambiguity. Code length: Generally appropriate for the functionality, but lengthy documentation and dead counting code add bulk. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Method boundaries and sequential operations support natural reading, although dense expressions, a long inline type-ignore comment, and types not defined or imported in this snippet interrupt comprehension.
Run 3
Code Structure: Methods logically separate session handling, request construction, and context management, but the unused even-number counting loop in __exit__ is unrelated clutter. Nesting: Mostly shallow, with moderate branching in open and unnecessary nesting in __exit__. Clarity of intent: Descriptive method names, type annotations, docstrings, and lifecycle comments explain most behavior; abbreviated variables and externally defined types require some context. Code length: Generally appropriate, though lengthy documentation, unused imports, and the irrelevant loop add bulk. Action granularity: Statements generally perform one action per line, with a few dense builder expressions and a long assignment reducing scanability. Reading flow: Request preparation, execution, and cleanup follow a natural sequence, but the stray loop and misleading 'request is None' comment interrupt that flow.