Sample
pyint-1d1f60d9c3d2-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.893 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 60 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.494 | 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. | 4437.184 | −146.427 |
| Source linesThe number of non-empty source lines. | 162 | +64.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.616 | −6.924 |
Intercept 8.87 + feature contributions = -79.681 (log-odds).
Score = sigmoid(-79.681) = 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. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 135 | +3.932 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.922 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 101.939 | +0.84 |
| 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. | 101.963 | −0.654 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.417 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 2.122 (log-odds).
Score = sigmoid(2.122) = 0.893.
| Score | 0.561 |
|---|
| Score | 60 |
|---|
Run 1
The code is highly readable with clear structure, minimal nesting, and explicit intent. Imports are logically grouped by source and alphabetized. The class has a clear docstring with examples, well-defined type hints, and defaults handled consistently. Each action in __init__ is concise, with one action per line, improving traceability. The prepare() method cleanly delegates to PreparedRequest. Minor deductions: the long import block adds vertical length, and some annotations (e.g., _t.UriType | None) slightly reduce readability for non-expert readers, but overall this is professional, maintainable code.
Run 2
The code is highly readable with clear logical organization, well-structured imports, and a straightforward class definition. The Request class has explicit type annotations, a comprehensive docstring with usage examples, and clear separation of concerns. The __init__ method uses a consistent pattern for default value handling with inline comments explaining the rationale. Nesting is minimal, with only one level in the hook registration loop. Each line performs a single action, maintaining good action granularity. The reading flow is natural, moving from class documentation to type declarations, then initialization logic, and finally methods. The code is concise without sacrificing clarity, avoiding unnecessary verbosity. Minor deductions: the import section is lengthy, though properly organized, and some type aliases like _t.UriType require checking the types module for full comprehension, slightly impacting immediate readability for newcomers.
Run 3
The code is highly readable due to its clear structure and organization. The imports are logically grouped, making dependencies easy to understand. The Request class has a well-documented docstring with clear parameter descriptions and usage examples. Type hints are used extensively, improving clarity and maintainability. The __init__ method handles default values concisely with conditional assignments. The nesting is flat, with no deeply nested logic. Each action has its own line, such as setting attributes or registering hooks. The reading flow is natural, progressing from imports to class definition, attributes, methods, and finally the prepare method. Minor deductions: the class depends on RequestHooksMixin and PreparedRequest which are not shown, slightly reducing standalone clarity. The default value assignments could be marginally simplified with a helper, but are acceptable. Overall, the code is clean, well-documented, and easy to follow.
Run 1
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation; however, many imports are unused in this excerpt, and referenced types and base classes are not defined here. Nesting: Control flow is shallow, with only one simple loop. Clarity of intent: Descriptive names, type annotations, and a usage example clearly explain request construction and preparation, though the variable names p, k, and v are less expressive. Code length: The implementation is concise, but extensive imports and documentation make the excerpt longer than its functionality requires. Action granularity: Statements generally perform one action per line, and multiline calls clearly separate arguments. Reading flow: Methods follow a natural lifecycle, and formatting is consistent; the large import block and external dependencies slightly interrupt otherwise straightforward reading.
Run 2
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation, although the extensive import block includes many names unused in this snippet. Nesting: Control flow is almost entirely flat, with only a simple hook-registration loop. Clarity of intent: Descriptive names, type annotations, and detailed documentation clearly communicate the request object's purpose; externally defined types and base classes require additional context. Code length: Methods are concise, but lengthy imports, documentation, and repeated field declarations and assignments add reading overhead. Action granularity: Statements generally perform one action per line, making initialization and delegation easy to inspect. Reading flow: Defaults, hook setup, field assignments, and preparation follow a natural sequence. Minor distractions include the generic variable name 'p' and a comment describing default dictionaries when data and files actually default to lists.
Run 3
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation, although the extensive imports distract from this small excerpt. Nesting: Control flow is flat, with only a simple loop. Clarity of intent: Descriptive method names, type annotations, parameter documentation, and a usage example clearly explain the request object's purpose. Some referenced types and the base class are not defined or imported in the excerpt, reducing standalone clarity. Code length: The implementation is concise, but lengthy documentation, imports, and repeated parameter lists add reading overhead. Action granularity: Statements generally perform one action per line, and multiline calls are easy to scan. Reading flow: Defaults, hook setup, attribute assignment, and preparation follow a natural sequence. Minor issues include abbreviated local names such as p, k, and v, and a comment describing empty dictionaries when some defaults are lists.