Sample
pyint-aab843b62cd2-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.006 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 197 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.358 | 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. | 13313.165 | −439.334 |
| Source linesThe number of non-empty source lines. | 428 | +171.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.484 | −6.726 |
Intercept 8.87 + feature contributions = -265.991 (log-odds).
Score = sigmoid(-265.991) = 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. | 428 | −14.118 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 339 | +10.989 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 339 | −7.358 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 427.97 | +5.572 |
| 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. | 133.972 | −2.009 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.988 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.051 | +0.45 |
Intercept 0.07 + feature contributions = -5.047 (log-odds).
Score = sigmoid(-5.047) = 0.006.
| Score | 0.561 |
|---|
| Score | 197 |
|---|
Run 1
The code demonstrates strong documentation and typing annotations, contributing to clarity. However, several factors reduce readability: the massive import block is daunting, and the presence of obfuscated/dead code (the `lI0O_34c16748` block in `prepare_headers`) is a major red flag that disrupts reading flow and signals poor maintainability. Methods like `prepare_url` and `prepare_body` are long and contain complex conditional logic, decreasing clarity. While generally well-structured, the use of multiple actions per line in some areas, along with commented-out type ignores and scattered TODO comments, detracts from the overall natural flow. The code is readable for experienced developers familiar with the codebase, but the unnecessary complexity and dead code prevent it from being highly readable.
Run 2
The code follows a logical class structure with clear method separation and docstrings, but several issues significantly hurt readability. The massive import block is overwhelming, and there's a suspicious obfuscated variable 'lI0O_34c16748' in prepare_headers that serves no purpose and breaks trust. Type annotations are comprehensive but add noise. Methods like prepare_url and prepare_body are very long with heavy branching and nested conditionals. Comments are excellent in places (explaining auth ordering, body position tracking) but some are unnecessary. The 'Nottin' on you' comment is unprofessional. Mixed concerns exist-some methods are clean (prepare_method, prepare_cookies), while others handle too much (prepare_body handles JSON, streaming, files, and form data). Line lengths are generally reasonable, but multiple operations per line appear in type-heavy sections. The reading flow is natural top-to-bottom, but vertical density makes comprehension challenging.
Run 3
The code has clear structure and descriptive names, but suffers from excessive length, complex type annotations, and some suspicious or confusing elements. The PreparedRequest class is logically organized with focused methods, but the prepare_url method is overly long with many conditionals and inline comments. Type hints are verbose and add visual noise, reducing readability. The presence of obfuscated code (the lI0O_34c16748 variable in prepare_headers) is highly problematic and undermines clarity. Import section is extensive but organized. Comments explain intent well, though some are unnecessary. Action granularity is generally good - one action per line. Reading flow is disrupted by deep nesting in prepare_body and prepare_url. The code mixes multiple abstraction levels within methods, making it harder to follow. Overall, it's maintainable by experienced developers familiar with the codebase, but not immediately accessible to newcomers.
Run 1
Code Structure: Well organized into focused preparation methods, although prepare_body combines several responsibilities. Nesting: Mostly shallow, but body serialization and streaming logic contain multiple nested conditionals and exception handlers. Clarity of intent: Descriptive method names, type annotations, and useful docstrings make the purpose clear; the cryptically named variable and unreachable arithmetic block in prepare_headers introduce obvious confusion. Code length: Most length reflects legitimate HTTP edge cases, but extensive imports, verbose comments, type-ignore annotations, and dead code add clutter. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The prepare method provides a natural overview of the processing sequence, and helper methods largely follow it. However, complex branching in prepare_body, occasional irrelevant comments, and the obfuscated header block interrupt that flow.
Run 2
Code Structure: Request preparation is logically divided into focused methods, with a clear orchestration method. Nesting: Most methods are shallow, but prepare_body has several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, and explanatory docstrings clarify behavior; the cryptic variable and pointless bitwise block in prepare_headers obscure intent. Code length: Most length reflects legitimate HTTP edge cases, although verbose comments, extensive imports, and dead code add clutter. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Preparation steps follow a natural sequence, and comments explain important ordering constraints. Flow is weakened by long inline type-ignore annotations, an irrelevant comment, and the complex body-handling method. Overall, readable and well organized, but unnecessary obfuscation and localized complexity prevent a higher score.
Run 3
Code Structure: Well-organized methods separate request preparation responsibilities, though prepare_body handles several complex cases. Nesting: Mostly shallow, but body preparation contains multiple nested conditionals and exception handlers. Clarity of intent: Descriptive method names, annotations, and explanatory documentation make the purpose clear; the cryptic variable and meaningless bitwise block in prepare_headers obscure intent. Code length: Generally justified by HTTP edge cases, but the dead-code block, extensive imports, and some redundant comments add clutter. Action granularity: Statements usually perform one action per line, making changes easy to follow. Reading flow: The prepare method establishes a natural processing sequence, and helper methods mostly follow that order. Long type-ignore comments, occasional unhelpful comments, and missing definitions for referenced mixins and types interrupt otherwise readable code.