Sample
pyint-41f8aef52e72-I11
Split eligible integer literals into pairs of short-named intermediate 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 | 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
This code is highly readable. It has clear logical organization, with imports grouped by type, a well-documented class, and explicit type annotations. Nesting is minimal; the class contains only flat methods with no deep indentation. The intent is immediately clear—defining a Request object for HTTP preparation. While the import block is long, it is concise for its purpose and unavoidable given the module's dependencies. Each action or initialization generally occupies one line, and the reading flow is natural from imports to class definition, docstring, attributes, methods, and helpers. Minor deductions are for the extensive imports and lack of a module docstring.
Run 3
The code demonstrates good structure and clarity overall. The __init__ method is well-organized with sensible defaults and minimal nesting. Type hints and thorough docstrings significantly aid readability. The assignments are logically grouped with clear intent. However, the extensive import block at the top is dense and could benefit from alphabetical organization or splitting into smaller logical groups. The type annotations, while helpful, add visual noise to parameter lists. The code is generally concise with one action per line, and the reading flow is natural. Minor improvements could include reducing the complexity of type hints and reorganizing imports for better scannability.
Run 1
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation, although numerous unrelated imports distract from the excerpt. Nesting: Control flow is nearly flat, with only a simple hook-registration loop. Clarity of intent: Descriptive names, type annotations, parameter documentation, and an example clearly explain the request object's purpose; undefined dependencies in the excerpt and the abbreviated variable p slightly reduce clarity. Code length: The implementation is concise, but extensive imports and repeated attribute and parameter declarations increase reading overhead. Action granularity: Statements generally perform one action per line, and multiline calls are easy to scan. Reading flow: Initialization and preparation proceed naturally in consistent parameter order, though the lengthy import section delays reaching the relevant logic.
Run 2
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation, although the large import block includes many names unused in this excerpt. Nesting: Control flow is almost entirely flat, with only a simple loop. Clarity of intent: Descriptive method names, type annotations, and a detailed docstring clearly explain request construction and preparation; abbreviated variables such as p, k, and v slightly reduce clarity. Referenced classes not defined or imported in the excerpt make standalone understanding harder. Code length: The implementation is concise, though extensive imports, documentation, and repeated parameter forwarding increase its size. Action granularity: Statements generally perform one action per line, and multiline calls make individual arguments easy to inspect. Reading flow: Initialization proceeds naturally from default normalization to hook registration and attribute assignment, followed by straightforward preparation. Overall, the code is highly readable, with minor contextual and verbosity-related distractions.
Run 3
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation, though the large import block contains many names unused in this snippet. Nesting: Control flow is shallow, with only a simple loop. Clarity of intent: Descriptive methods, type annotations, and detailed parameter documentation clearly communicate the request object's purpose; abbreviated variables such as p, k, and v slightly reduce clarity. Code length: The implementation is concise, but extensive imports, annotations, and documentation make this small class lengthy. Action granularity: Statements generally perform one action per line, and keyword arguments are clearly separated. Reading flow: Initialization and preparation follow a natural sequence, although missing definitions or imports for RequestHooksMixin and cookie-related types require external context.