Sample
pyint-3db971294934-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.007 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 192 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.386 | 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. | 12993.171 | −428.775 |
| Source linesThe number of non-empty source lines. | 422 | +168.8 |
| 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.466 | −6.699 |
Intercept 8.87 + feature contributions = -257.804 (log-odds).
Score = sigmoid(-257.804) = 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. | 423 | −13.941 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 333 | +10.781 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 333 | −7.22 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 421.956 | +5.488 |
| 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.979 | −2.01 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.983 | +1.357 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.456 |
Intercept 0.07 + feature contributions = -5.019 (log-odds).
Score = sigmoid(-5.019) = 0.007.
| Score | 0.561 |
|---|
| Score | 192 |
|---|
Run 1
The code demonstrates good readability with clear method separation and logical organization. Each prepare_* method handles one aspect of request preparation, following single responsibility. The structure is flat with minimal deep nesting - the deepest nesting occurs in prepare_body and prepare_url with 2-3 levels, which is acceptable. Comments effectively explain non-obvious logic like IDNA encoding and auth ordering. Type hints improve clarity significantly. The code is somewhat verbose due to extensive docstrings and type annotations, but this enhances maintainability. Most lines perform one action, though some conditional expressions could be split. The flow is natural: initialization, then preparation methods in logical order (method, URL, headers, cookies, body, auth, hooks). Minor deductions for import clutter and some dense sections in prepare_body where multiple operations occur per line. Overall, this is production-quality code that balances explicitness with readability.
Run 2
The code demonstrates strong readability through clear class structure, meaningful method names, and logical organization. The PreparedRequest class has well-defined responsibilities with each prepare_* method handling a specific aspect. Nesting is moderate but never excessive, with early returns avoiding deep indentation. Comments explain non-obvious decisions and ordering requirements without being excessive. Type hints are used extensively, improving clarity. The code length is appropriate for the complexity of the task, though some methods like prepare_url and prepare_body are quite long. Action granularity is generally good - most lines perform one operation. Reading flow is natural, with methods following a logical preparation sequence. Minor deductions: long import block is standard for the library, some type ignore comments add noise, and the 'Nottin' on you' comment is unprofessional. The conditional logic in prepare_body could be simplified, but overall this is production-quality, maintainable code that clearly communicates its intent.
Run 3
The code is well-structured with clear class separation and logical method organization. Each method serves a specific purpose with descriptive docstrings. Nesting is mostly controlled, though prepare_url and prepare_body contain several conditional levels. The intent of each method is clear despite complex HTTP preparation logic. Length is moderate for the complexity handled, though some methods like prepare_url are lengthy. Action granularity is generally good with one action per line. Reading flow is natural with methods ordered logically, helpful comments, and type hints. Minor issues include some deeply nested conditionals in prepare_body, occasional verbose comments, and complex type annotations that could reduce readability for developers unfamiliar with the codebase.
Run 1
Code Structure: Well organized into focused preparation methods, with a clear orchestration method separating responsibilities. Nesting: Mostly shallow, although prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, docstrings, and explanatory comments make the HTTP preparation logic understandable; vague comments and abbreviated variables such as p and r weaken clarity slightly. Code length: Generally justified by protocol handling, but the extensive imports, repetitive documentation, and long body-preparation method add reading overhead. Action granularity: Statements generally perform one action per line, with no compressed multi-statement sequences. Reading flow: Preparation follows a natural sequence, and comments explain ordering dependencies and edge cases. However, inline type-ignore annotations, compatibility details, and references to types and mixins not defined in this excerpt interrupt the flow.
Run 2
Code Structure: Well organized into focused preparation methods, with a central prepare method coordinating the process. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, and documentation explain most behavior; cryptic comments, short variables such as p and r, and numerous casts/type-ignore annotations add noise. Code length: Generally justified by HTTP edge cases, although lengthy comments, a broad import section, and the large prepare_body method reduce concision. Action granularity: Statements generally perform one action per line, making mutations and validation steps easy to follow. Reading flow: Preparation proceeds naturally from method and URL through headers, cookies, body, authentication, and hooks, with ordering constraints documented. Flow becomes less straightforward within body handling and authentication's indirect state updates.
Run 3
Code Structure: Well organized into focused preparation methods, with a clear orchestration method separating request components. Nesting: Mostly shallow, but prepare_body contains several nested branches and exception handlers that increase cognitive load. Clarity of intent: Descriptive method names, type annotations, and docstrings explain responsibilities; cryptic names such as p and r, unexplained external types, and an irrelevant comment slightly weaken clarity. Code length: Generally justified by HTTP edge cases, though lengthy imports, verbose comments, and typing suppressions add clutter; prepare_body could be decomposed further. Action granularity: Statements generally perform one action per line, making state changes easy to identify. Reading flow: Preparation follows a natural sequence, with comments explaining important ordering constraints. Flow becomes less straightforward in body encoding and authentication because of branching, casts, and dynamic state updates.