Sample
pyint-0cdee83adc3d-I06
Invert eligible conditions and exchange their branches
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
The code is highly readable. It has a clear class structure with a well-documented docstring, including a usage example. Type hints are used consistently, which aids clarity. The constructor uses a flat structure, handling default values in a clear, sequential manner with one action per line. The `prepare` method cleanly delegates to `PreparedRequest`, making the intent obvious. While the import section is long, it is logically organized by source (stdlib, third-party, local modules). The `__repr__` method is concise. Potential minor deductions: the import block can look verbose, and a few type aliases (like `_t.UriType`) add indirection, but overall the code is easy to follow and well-structured.
Run 3
The code is highly readable overall. Structure is logical: imports are grouped by origin, the class is well-organized with clear type annotations, and methods are concise. Nesting is minimal — the __init__ method stays flat despite many parameters. Intent is explicit through descriptive parameter names, type hints, and a detailed docstring. Code length is justified; the long import block reflects the module's dependencies and is organized. Action granularity is appropriate, with one assignment or call per line in the constructor. Reading flow is natural: class attributes are declared first, followed by __init__, __repr__, and prepare. Minor deductions: some default-value assignments (e.g., data = [] if data is None else data) could be simplified with or-expressions, and the numerous imports slightly increase visual overhead. However, these are minor and do not hinder comprehension significantly.
Run 1
Code Structure: The class is logically organized into documentation, type declarations, initialization, representation, and preparation, although the large import block includes many names unused in this excerpt. Nesting: Control flow is mostly flat, with only a simple loop. Clarity of intent: Descriptive names, type annotations, and detailed documentation clearly explain request construction and preparation; the abbreviated variable p and externally defined dependencies slightly reduce immediate clarity. Code length: The implementation is concise, but extensive imports, documentation, and repeated parameter forwarding increase scanning effort. Action granularity: Statements generally perform one action per line, and multiline calls make arguments easy to inspect. Reading flow: Methods follow a natural lifecycle and formatting is consistent, though the long preamble delays reaching the main behavior.
Run 2
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation methods, although the extensive imports obscure its beginning. Nesting: Control flow is shallow, with only a simple loop. Clarity of intent: Descriptive method names, type annotations, and comprehensive documentation make the request-building purpose clear; abbreviated variables such as p, k, and v are less informative, and several referenced types and the base class are not defined or imported in the excerpt. Code length: The implementation is concise, but the large import section includes many names unused in the shown code, and documentation and repeated declarations add scanning overhead. Action granularity: Statements generally perform one action per line, with clearly formatted multiline calls. Reading flow: Initialization progresses naturally from defaults to hooks and attributes, followed by straightforward request preparation; import clutter slightly interrupts an otherwise coherent flow.
Run 3
Code Structure: The class is logically organized into documentation, attribute declarations, initialization, representation, and preparation, although many imports appear unrelated to this excerpt. Nesting: Control flow is nearly flat, with only a simple hook-registration loop. Clarity of intent: Descriptive method and attribute names, type annotations, and a detailed docstring clearly explain request construction and preparation; externally defined types and base classes require additional context. Code length: The implementation is concise, but extensive imports, repeated parameter declarations, and attribute forwarding add visual bulk. Action granularity: Statements generally perform one action per line, making assignments and preparation arguments easy to inspect. Reading flow: Initialization proceeds naturally from default normalization to hooks and attribute assignment, followed by preparation. The lengthy import section delays reaching the central logic, but the class itself is straightforward to follow.